Query.Fields[x] = ftBlob, ich benötige aber ftByte

[juergen]

Hallo zusammen,

ich benötige ein Query.Fields[x] vom Datentyp ftByte.
Die Tabellenspalte ist wie folgt definiert:

Code:

[x] [varbinary](max) NOT NULL

Wenn ich im Select folgendes anwende, erhalte ich in Delphi in meinem FireDac-Query-Field den Datentyp ftByte:

Code:

Select
  CONVERT(BINARY, A.x)

Dann fehlen mir aber in einigen Zeilen Werte. BINARY ist einfach zu "kurz".

Wenn ich im Select folgendes anwende, erhalte ich in meiner FireDac-Query-Field den Datentyp ftBlob.

Code:

Select
  CONVERT(VARBINARY(MAX), A.x)

Hiermit sind aber zumindest alle Werte vollständig.

Gibt es irgendeine Möglichkeit als Ergebnis eines FireDac-Query-Fields anstelle ftBlob ftByte zu erhalten?

Oder kann man "einfach" DataModul_1.Qry_A.Fields[4].AsBytes anwenden, obwohl das Field eigentlich ftBlob ist?

Das eigentliche Ziel soll sein, dass das ftByte (oder wenn es geht) auch das ftBlob in ein String umgewandelt werden muss. In den Bytes können aber alle möglichen Zeichen vorkommen, u.a auch Zeichen für Textende, so dass viele String-Operationen dann abbrechen.

[himitsu]

wirklich ftByte .... ein Byte ?

Oder meinst du eher ftBytes, bzw. ftVarBytes?
Also sowas wie CHAR und VARCHAR,
während ftBlob mehr sowas wie TEXT ist.

[edit]
Hmmm ... Byte ... Bytes ... hmmmmmmmmmmm

Zitat:

Zitat von Data.Bind.DBScope.pas

Delphi-Quellcode:

mtUInteger,  // TByteField,                { ftByte }

ftByte doch mehr als 1 ? :gruebel:
[/edit]
[edit2]

Zitat:

TByteField represents a field that contains a byte value in a dataset.
TByteField encapsulates the fundamental behavior common to fields that contain byte data. Byte fields can hold values in the range 0 to 255, and are frequently used to hold small numerical values.

Doch richtig, sagt die Hilfe :)

ftByte kannte sie zwar, aber ohne Beschreibung dazu.
[/edit2]


Erstmal muß FireDac es auch "können" diesen Datenbank-FieldTyp in die Daten dieses Delphi-Fields zu übernehmen.
Dann brauchst du auch noch den passenden TField-Typen, zum ftBytes.

und wenn das geht:

entweder du erstellst die TField's selber
oder du mußt irgendwo den Typen registrieren.



Irgendwo gibt es Übersetzungstabellen (Arrays/Listen), in welchen drin steht, was zu wem übersetzt wird.
z.B. INTEGER -> eventuell noch ein ZwischenTyp in der DB-Komponente und noch Einer in der Datenbank-API -> ftInteger -> TIntegerField -> und zum Schluß haben besserere DBGrids bestimmt nochmal eine Übersetzung zum Column-Type

Zitat:

Das eigentliche Ziel soll sein, dass das ftByte (oder wenn es geht) auch das ftBlob in ein String umgewandelt werden muss. In den Bytes können aber alle möglichen Zeichen vorkommen, u.a auch Zeichen für Textende, so dass viele String-Operationen dann abbrechen.

Und wenn die Codepage / Codierung das nicht mag, dann raucht es ganz ab.

Wenn, dann natürlich so in einen String konvertieren, dass diese Probleme nicht auftauchen.
z.B. HEX, Base64, oder nur die "bösen" Zeichen irgendwie maskieren oder ersetzen.

[juergen]

Das Thema ist erledigt! Ja, es ging um TBytes.
Der Firedac Datenbanktreiber liest die Werte bei MSSQL nun korrekt aus. Bei einer Pervasive Datenbank (über ODBC) aber nicht. Wenn es in dem Feld eine Zeichenfolge für Textende gibt, bricht FireDac ab, obwohl FireDac das Feld als TBytes erkennt. Es kommt keine Fehlermeldung. Auch Pervasive selbst gibt im PCC nicht die Werte aus. Man kommt da anscheinend nur über native Btrieve dran. Ich probiere mal die original Hersteller PDAC‘s.

[Frickler]

VarBinary(max) ist ein Blob-Feld. Siehe auch hier.

Zugriff dann eher mit LoadFromStream/SaveToStream statt AsBytes, würde ich sagen.