Lesen/Schreiben von BINARY(16) über DataSet

[himitsu]

[EDIT]
Es ist alles Richtig. DU hast gesagt du willst einen STRING, also hat die DB dir auch einen STRING gegeben.

Zitat von BINARY:

Zum Speichern binärer Strings, unabhängig vom Zeichensatz. Wertebereich für M: 0 bis 255. Weiterer Typ: VARBINARY

https://www.schmager.de/mysql.php

Du wolltest bestimmt den Typ "BLOB", bzw. BLOB(16) verwenden?
(einige andere DBMS bieten sogar direkt einen Typen für GUID, inkl. einer automatischen VARCHAR-Konvertierung, falls man sowas braucht)

Aber ja, ich hätte unter "BINARY" auch erstmal was Anderes verstanden
[/EDIT]


DBTypen, welche die Query-Komponente nicht versteht, bzw. nicht implementiert hat, weichen als Ersatz gern auf VARCHAR aus.

Und da UTF-8 in DBMS nunmal statisch 3 (bis 5) Byte pro Char reserviert, passen in 16 Byte zufällig nur 5 Chars rein.

• entweder du nutzt eine andere DBKomponente, welche z.B. genau auf das gewünschte DBMS ausgelegt ist
• 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)
• oder du spielst am TypeMapping rum, wo du selbst ensprechend die DBTypen zum gewüünschten TField-Typ definierst
• oder ...

[Edelfix]

Bin aktuell mit gleichem Problem beschäftigt.

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

Jetzt kommt aber folgendes:

Version 1: Mit Klammern {GUID} - Ist für Windows Registry, COM, einige Konfig-Dateien
Version 2: Ohne Klammern - Ist für "GUID APIs", JSON, allgemeine Programmierung

Also stelle ich auf Char(38) um damit beides funktioniert.

[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.