Lesen/Schreiben von BINARY(16) über DataSet

[tumo]

Ist ja auch nicht falsch, es gibt ja aber auch (zumindest im FireDac TFDDataType) ein "dtByteString". Mein Problem ist ja nicht unbedingt, dass er es als String anbietet, sondern, dass er da Konvertierungen macht. Ein "BINARY" ist ja ein String von Bytes, da soll er wenn ich explizit Bytes zuweise auch nichts mehr dran rütteln.

Ein "BLOB(16)" würde auch gehen, korrekt. Blöd daran ist, dass es nicht eine Länge von 16 forciert und einen zusätzlichen Byte für die tatsächliche Länge verbraucht. MySQL sagt selber, dass sie für GUIDs einen BINARY(16) empfehlen https://dev.mysql.com/blog-archive/s...-mysql-tables/

Zitat:

oder du erstellst selber die TField (TBlobField) und richtest sie passend ein (BlobType=ftBlob)
(Dank dem neuen MixedMode muß man nun auch nicht mehr ALLE Felder selbst erstellen, sondern nur noch die Nötigen)

Kannst du mich da noch in die richtige Richtung schubsen? Wie mache ich das in FireDAC bzw. wie heißt das Konzept da?

Zitat:

oder du spielst am TypeMapping rum, wo du selbst ensprechend die DBTypen zum gewüünschten TField-Typ definierst

Das hatte ich mit den FireDac MapRules schon versucht, Problem hierbei ist, dass ich schon die "konvertierten" Datentypen bekomme und die Größe nicht mehr anpassen darf.
Also ich könnte eine Rule machen:

Delphi-Quellcode:

with MapRules.Add do
begin
  SourceDataType := dtWideString;
  SizeMin := 5; SizeMax := 5;
  TargetDataType := dtByteString;
end;

Und ich bekomme den gewünschten Typ "ftBytes" raus, aber die Size ist trotzdem nur 5. (Zudem finde ich das ein wenig "hacky". Was, wenn ich tatsächlich einen String von 5 Chars speichern will?)

Zitat:

Habe mich für Char(36) entschieden als Ersatz für ein GUID Feld Type in ADS.

Das war jetzt auch erstmal meine Lösung. Ich habe mich aber nicht den Microsoft-Göttern gebeugt und truncate eiskalt die Klammern. Hat den Hintergrund, dass mein DBMS auch UUIDs erstellen kann, das aber ohne die Klammern arbeitet.