Mvsql-string-literale im Jitterbit App Builder
Der SQL-Standard definiert zwei Zeichenfolgentypen mit jeweils eigener Literalsyntax.
ANSI - National
ANSI-Zeichenfolgen stellen ASCII und andere Einzelbyte-Zeichensätze dar, wie beispielsweise EBCDIC auf DB2/i.
Nationale Zeichenfolgen stellen Mehrbyte-Zeichensätze wie Unicode dar.
Der SQL-Standard definiert für jeden Zeichenfolgentyp eine eigene Literalsyntax. Die Syntax für ein ANSI-Zeichenfolgenliteral lautet:
'Aristotle''s quotes'
Beachten Sie, dass einfache Anführungszeichen im Stringliteral durch Verdoppelung des einfachen Anführungszeichens maskiert werden.
Die Syntax für ein nationales Stringliteral lautet:
N'Aristotle''s quotes'mvSQL unterstützt die SQL-Standardsyntax für ANSI- und nationale Zeichenfolgenliterale.
Notiz
Die Verwendung einer falschen SQL-Literalsyntax kann zu erheblichen Leistungseinbußen führen. Bei einer Spalte, die Daten in einem ANSI-Zeichensatz speichert, nutzt eine Suchbedingung mit einem National-String-Literal keine Indizes und erzwingt eine Konvertierung der Spaltenwerte.
Einige Datenbanken, wie z. B. Oracle, unterstützen keine impliziten Konvertierungen zwischen Zeichensätzen. Durch die Verwendung der entsprechenden Zeichenfolgenliteralsyntax werden Fehler vermieden und explizite Konvertierungen überflüssig.
Anbieterunterstützung
Sofern nicht anders dokumentiert, werden ANSI- und nationale Zeichenfolgenliterale direkt dem nativen Anbieteräquivalent zugeordnet.
MySQL
MySQL definiert keine separate Syntax für ANSI- und nationale Zeichenfolgenliterale. In MySQL wird davon ausgegangen, dass die Zeichenfolgenliterale mit dem Zeichensatz der Verbindung kodiert sind. Das bedeutet, dass die Kodierung je nach Verbindungseinstellungen variieren kann. Wenn die Verbindung eine ANSI-Kodierung verwendet (z. B. die Standardkodierung latin1), werden alle Zeichenfolgen als ANSI-Zeichenfolgen angenommen.
Notiz
App Builder verwendet standardmäßig den UTF-8-Zeichensatz für MySQL Verbindungen. Verwenden Sie den Parameter CharSet, um den Zeichensatz für MySQL Verbindungen zu ändern. Um beispielsweise den MySQL -Standard-ASCII-Zeichensatz zu verwenden, fügen Sie in den erweiterten Einstellungen CharSet=latin1 hinzu.
MySQL unterstützt Zeichensatz-Introducer. Der „Introducer“ ist ein Präfix, das dem Zeichenfolgenliteralwert vorangestellt wird. Es gibt den Zeichensatz der Zeichenfolge an. App Builder verwendet Zeichensatz-Introducer, um sicherzustellen, dass Unicode-Daten unabhängig von den Verbindungseinstellungen in Zeichenfolgenliteralen kodiert werden können. Umgekehrt stellt der Zeichensatz-Introducer bei einer Verbindung mit dem Zeichensatz UTF-8 sicher, dass ASCII-Daten als ASCII an den Server übergeben werden, wodurch problematische Konvertierungen vermieden werden.
In der Praxis bedeutet dies, dass ein mvSQL ANSI-Zeichenfolgenliteral wie folgt übersetzt wird:
_latin1'Aristotle''s quotes'Ein mvSQL National-Zeichenkettenliteral wird wie folgt in die MySQL-Syntax übersetzt:
_utf8'Aristotle''s quotes'
MySQL definiert keine separaten Speicherdatentypen für ANSI- und nationale Zeichentypen. Stattdessen werden alle Zeichenfolgentypen in einem gemeinsamen Datentyp gespeichert. Der Zeichensatz bestimmt die Art der Datenspeicherung. App Builder ordnet MySQL Zeichenspalten mit einem Unicode-Zeichensatz (utf8) dem entsprechenden, herstellerneutralen nationalen Zeichenfolgentyp (z. B. NCHAR oder NVARCHAR) zu.
DB2/i
Wie MySQL verfügt auch DB2/i nicht über separate Datentypen für ANSI- und nationale Zeichenketten. Stattdessen bestimmt die CCSID die Kodierung. Die CCSID ist eine vorzeichenlose 16-Bit-Ganzzahl. Sie ähnelt der Windows LCID.
Wie bei MySQL prüft App Builder die CCSID, um einen DB2/i-Zeichentyp (z. B. VARCHAR) korrekt einem herstellerneutralen App Builder-Datentyp (z. B. NVARCHAR) zuzuordnen. Die folgenden CCSIDs werden dem NVARCHAR-Datentyp zugeordnet:
1200 UTF-16 - 1208 - UTF-8 - 13488 - UCS-2
Wenn Sie hingegen Spalten mit dem Datentyp „National Character“ erstellen, legt App Builder die CCSID explizit fest. Genauer gesagt setzt App Builder die CCSID auf 1208 (UTF-8).
Schließlich muss DB2/i keine separate Syntax für ANSI- und nationale Zeichenfolgen haben. Daher wird für beide die gleiche Syntax verwendet.
Nicht-RDBMS-Datenquellen
mvSQL National-String-Literale werden für Nicht-RDBMS-Datenquellen wie REST und Salesforce usw. nicht unterstützt.
Weiterführende Literatur
https://learn.microsoft.com/en-us/sql/relational-databases/collations/collation-and-unicode-support
https://docs.microsoft.com/en-us/sql/t-sql/data-types/constants-transact-sql
https://dev.mysql.com/doc/refman/8.0/en/charset-introducer.html