Im allgemeinen wird der für eine Anwendung verfügbare Zeichensatz vom Datenbankmanager nicht eingeschränkt. Eine detaillierte Erläuterung zu Mehrbytezeichensätzen (MBCS), die von DB2 unterstützt werden, finden Sie im Handbuch Application Development Guide.
Der Standardzeichensatz, der für Datenbanknamen verwendet werden kann, besteht aus den großen und kleinen Einzelbytebuchstaben des lateinischen Alphabets (A...Z, a...z), den arabischen Ziffern (0...9) und dem Unterstreichungszeichen (_). Diese Liste wird noch um drei Sonderzeichen (#, @ und $) erweitert, um Kompatibilität mit den Host-Datenbankprodukten zu gewährleisten. Allerdings sind diese Sonderzeichen in einer NLS-Umgebung mit Vorsicht zu verwenden, da sie nicht im unveränderlichen Zeichensatz für NLS-Hosts (EBCDIC) enthalten sind.
Beim Benennen von Datenbankobjekten (wie Tabellen und Sichten), Programmkennsätzen, Host-Variablen und Cursorn können auch Elemente aus dem erweiterten Zeichensatz (z. B. Buchstaben mit diakritischen Zeichen) verwendet werden. Welche Zeichen im einzelnen verfügbar sind, hängt von der verwendeten Codepage ab. Wenn Sie die Datenbank in einer Umgebung mit mehreren Codepages verwenden, müssen Sie darauf achten, daß alle Codepages die Elemente aus dem erweiterten Zeichensatz unterstützen, die Sie verwenden möchten. Informationen zu begrenzten Bezeichnern, die Zeichen außerhalb des erweiterten Zeichensatzes enthalten, jedoch in SQL-Anweisungen verwendet werden können, finden Sie im Handbuch SQL Reference.
In DBCS-Umgebungen umfaßt der erweiterte Zeichensatz alle Zeichen des Standardzeichensatzes plus die folgenden Elemente:
Die Codierung von SQL-Anweisungen ist nicht sprachenabhängig. SQL-Schlüsselwörter können in Großbuchstaben, Kleinbuchstaben oder in gemischter Schreibweise eingegeben werden. Die Namen von Datenbankobjekten und Host-Variablen sowie Programmbezeichnungen in einer SQL-Anweisung dürfen keine Zeichen enthalten, die nicht in dem oben beschriebenen erweiterten Zeichensatz enthalten sind.
Die folgenden bidirektionalen Attribute sind erforderlich für die korrekte Behandlung bidirektionaler Daten auf unterschiedlichen Plattformen:
- Textart (LOGICAL oder VISUAL) - Gestaltung (SHAPED oder UNSHAPED) - Ausrichtung (RIGHT-TO-LEFT oder LEFT-TO-RIGHT) - Zeichengestaltung (ARABIC oder HINDI) - Symmetrische Auslagerung (YES oder NO)
Da die Standardeinstellungen auf den unterschiedlichen Plattformen nicht gleich sind, können Probleme auftreten, wenn DB2-Daten von einer Plattform auf eine andere übertragen werden. Das Windows-Betriebssystem verwendet beispielsweise Daten im Format LOGICAL UNSHAPED, während OS/390 im allgemeinen mit Daten im Format SHAPED VISUAL arbeitet. Daten, die ohne Unterstützung für bidirektionale Attribute von DB2 Universal Database für OS/390 auf DB2 UDB unter 32-Bit-Windows-Betriebssysteme übertragen werden, können daher falsch angezeigt werden.
DB2 unterstützt bidirektionale Datenattribute über spezielle bidirektionale IDs für codierte Zeichensätze (CCSIDs). Die folgenden CCSIDs für bidirektionale Zeichen wurden definiert und mit DB2 UDB implementiert:
CCSID | CCSID | Code- | Zeichenfolge- (dez) | (hex) | page | Type -------+--------+--------+-------- 00420 x'01A4' 420 4 00424 x'01A8' 424 4 08612 x'21A4' 420 5 08616 x'21A8' 424 10 00856 x'0358' 856 5 00862 x'035E' 862 4 00864 x'0360' 864 5 00916 x'0394' 916 5 01046 x'0416' 1046 5 01089 x'0441' 1089 5 01255 x'04E7' 1255 5 01256 x'04E8' 1256 5 62208 x'F300' 856 4 62209 x'F301' 862 10 62210 x'F302' 916 4 62211 x'F303' 424 5 62213 x'F305' 862 5 62215 x'F307' 1255 4 62218 x'F30A' 864 4 62220 x'F30C' 856 6 62221 x'F30D' 862 6 62222 x'F30E' 916 6 62223 x'F30F' 1255 6 62224 x'F310' 420 6 62225 x'F311' 864 6 62226 x'F312' 1046 6 62227 x'F313' 1089 6 62228 x'F314' 1256 6 62229 x'F315' 424 8 62230 x'F316' 856 8 62231 x'F317' 862 8 62232 x'F318' 916 8 62233 x'F319' 420 8 62234 x'F31A' 420 9 62235 x'F31B' 424 6 62236 x'F31C' 856 10 62237 x'F31D' 1255 8 62238 x'F31E' 916 10 62239 x'F31F' 1255 10 62240 x'F320' 424 11 62241 x'F321' 856 11 62242 x'F322' 862 11 62243 x'F323' 916 11 62244 x'F324' 1255 11 62245 x'F325' 424 10 62246 x'F326' 1046 8 62247 x'F327' 1046 9 62248 x'F328' 1046 4 62249 x'F329' 1046 12 62250 x'F32A' 420 12
Dabei sind CDRA-Zeichenfolgearten wie folgt definiert:
Zeichen-| Text- | Zeichen- | Ausrichtung | Gestaltung| Symmetrische folgeart| art | gestaltung | | | Auslagerungsfunktion --------+--------+------------+-------------+-----------+---------------------- 4 VISUAL PASSTHRU LTR SHAPED OFF 5 IMPLICIT ARABIC LTR UNSHAPED ON 6 IMPLICIT ARABIC RTL UNSHAPED ON 7(*) VISUAL ARABIC CONTEXTUAL(*) UNSHAPED-Lig OFF 8 VISUAL ARABIC RTL SHAPED OFF 9 VISUAL PASSTHRU RTL SHAPED ON 10 IMPLICIT PASSTHRU CONTEXTUAL-L UNSHAPED ON 11 IMPLICIT PASSTHRU CONTEXTUAL-R UNSHAPED ON 12 IMPLICIT ARABIC RTL SHAPED ON
Anmerkung: | (*) Die Feldausrichtung ist von links nach rechts (LTR), wenn das erste alphabetische Zeichen ein lateinisches Zeichen ist, und von rechts nach links (RTL), wenn es ein bidirektionales Zeichen ist. Zeichen sind UNSHAPED, LamAlef-Ligaturen werden jedoch beibehalten und nicht in Bestandteile getrennt. |
Bidirektionale Layoutumsetzungen werden in DB2 Universal Database mit den neuen CCSID-Definitionen implementiert. Bei den neuen spezifischen CCSIDs für bidirektionale Zeichen werden Layoutumsetzungen anstatt oder zusätzlich zur Umsetzung von Codepages durchgeführt. Damit diese Unterstützung verwendet werden kann, muß die Registrierungsvariable DB2BIDI auf YES gesetzt werden. Standardmäßig ist diese Variable nicht gesetzt. Sie wird vom Server für alle Umsetzungen verwendet und kann nur gesetzt werden, wenn der Server gestartet ist. Das Einstellen von DB2BIDI auf YES kann sich wegen der zusätzlichen Prüfung und der Layoutumsetzungen auf die Leistung auswirken.
Wenn Sie eine bestimmte CCSID für bidirektionale Zeichen in einer Nicht-DRDA-Umgebung angeben wollen, wählen Sie die CCSID (aus obiger Tabelle) aus, die den Kenndaten Ihres Clients entspricht, und stellen DB2CODEPAGE auf diesen Wert ein. Wenn Sie bereits eine Verbindung zur Datenbank haben, müssen Sie den Befehl TERMINATE absetzen, und die Verbindung anschließend erneut herstellen, damit die Einstellung von DB2CODEPAGE wirksam wird. Wenn Sie eine CCSID auswählen, die für die Codepage oder die Zeichenfolgeart Ihrer Client-Plattform nicht geeignet ist, erhalten Sie möglicherweise unerwartete Ergebnisse. Wenn Sie eine inkompatible CCSID (z.B. CCSID für Hebräisch zur Verbindung zu einer arabischen Datenbank) verwenden oder wenn DB2BIDI nicht für den Server eingestellt wurde, erhalten Sie eine Fehlernachricht, wenn Sie versuchen, die Verbindung herzustellen.
Wenn bei DRDA-Umgebungen die HOST-EBCDIC-Plattform diese CCSIDs für bidirektionale Zeichen ebenfalls unterstützt, müssen Sie nur den Wert für DB2CODEPAGE einstellen. Wenn die HOST-Plattform diese CCSIDs jedoch nicht unterstützt, müssen Sie eine CCSID-Überschreibung für den HOST-Datenbankserver angeben, zu dem Sie eine Verbindung herstellen. Dies ist notwendig, da in einer DRDA-Umgebung Umsetzungen von Codepages und Layoutumsetzungen vom Empfänger der Daten durchgeführt werden. Wenn der HOST-Server diese CCSIDs jedoch nicht unterstützt, wird keine Layoutumsetzung für die Daten durchgeführt, die er von DB2 UDB empfängt. Wenn Sie eine CCSID-Überschreibung verwenden, führt der Client unter DB2 UDB die Layoutumsetzung auch für die abgehenden Daten durch. Weitere Informationen zur Einstellung einer CCSID-Überschreibung finden Sie im DB2 Connect Benutzerhandbuch.
Die CCSID-Überschreibung wird nicht unterstützt, wenn die HOST-EBCDIC-Plattform der Client und DB2 UDB der Server ist.
Wenn Daten zwischen DB2 Connect und einer Datenbank auf dem Server ausgetauscht werden, ist es normalerweise die Empfängermaschine, die die Umsetzung der ankommenden Daten ausführt. Dasselbe würde normalerweise auch auf bidirektionale Layoutumsetzungen zutreffen, die zusätzlich zur üblichen Codepage-Umsetzung erfolgen. DB2 Connect kann wahlfrei bidirektionale Layoutumsetzungen an den Daten ausführen, die gerade an die Server-Datenbank gesendet werden, zusätzlich zu den Daten, die von der Server-Datenbank empfangen wurden.
Damit DB2 Connect bidirektionale Layoutumsetzungen an abgehenden Daten für eine Server-Datenbank ausführen kann, muß die bidirektionale CCSID der Server-Datenbank überschrieben werden. Dies wird durch die Verwendung des Parameters BIDI im Feld PARMS des DCS-Datenbankverzeichniseintrags für die Server-Datenbank erreicht.
Anmerkung: | Wenn Sie möchten, daß DB2 Connect eine Layoutumsetzung an den Daten ausführt, die gerade an die DB2-Host-Datenbank gesendet werden, müssen Sie ihre CCSID nicht überschreiben, aber Sie müssen den Parameter BIDI dem Feld PARMS des DCS-Datenbankverzeichnisses hinzufügen. In diesem Fall sollten Sie als CCSID die Standard-CCSID der DB2-Host-Datenbank angeben. |
Der Parameter BIDI muß als neunter Parameter im Feld PARMS zusammen mit der bidirektionalen CCSID, mit der Sie die bidirektionale Standard-CCSID der Server-Datenbank überschreiben wollen, angegeben werden:
",,,,,,,,BIDI=xyz"
Dabei gilt folgendes: xyz ist die CCSID-Überschreibung.
Anmerkung: | Die Registrierungsvariable DB2BIDI muß auf den Wert YES gesetzt werden, damit der Parameter BIDI wirksam werden kann. |
Eine Liste der unterstützten bidirektionalen CCSIDs finden Sie zusammen mit ihren Zeichenfolgearten in Spezifische CCSIDs für bidirektionale Zeichen.
Die Verwendung dieser Einrichtung wird am besten an einem Beispiel erläutert.
Angenommen, Sie haben einen hebräischen DB2-Client, der CCSID 62213 (bidirektionale Zeichenfolgeart 5) ausführt, und Sie wollen auf eine DB2-Host-Datenbank zugreifen, die CCSID 00424 (bidirektionale Zeichenfolgeart 4) ausführt. Sie wissen aber, daß die in der DB2-Host-Datenbank enthaltenen Daten auf der CCSID 08616 (bidirektionale Zeichenfolgeart 6) basieren.
Hier gibt es zwei Probleme: Das erste Problem besteht darin, daß die DB2-Host-Datenbank den Unterschied zwischen den bidirektionalen Zeichenfolgearten mit den CCSIDs 00424 und 08616 nicht kennt. Das zweite Problem ist, daß die DB2-Host-Datenbank die DB2-Client-CCSID (62213) nicht erkennt. Sie unterstützt nur CCSID 00862, die auf derselben Codepage wie CCSID 62213 basiert.
Sie müssen zunächst sicherstellen, daß die an die DB2-Host-Datenbank gesendeten Daten das Format der bidirektionalen Zeichenfolgeart 6 haben. Ferner müssen Sie DB2 Connect bekanntgeben, daß eine bidirektionale Umsetzung der Daten ausgeführt werden soll, die von der DB2-Host-Datenbank empfangen werden. Sie müssen den folgenden Katalogisierungsbefehl für die DB2-Host-Datenbank verwenden:
db2 catalog dcs database nydb1 as telaviv parms ",,,,,,,,BIDI=08616"
Mit diesem Befehl wird DB2 Connect mitgeteilt, daß die CCSID 00424 der DB2-Host-Datenbank mit der CCSID 08616 überschrieben werden soll. Diese Überschreibung wird wie folgt verarbeitet:
Anmerkung: | In einigen Fällen kann die Verwendung einer bidirektionalen CCSID die
SQL-Abfrage selbst so ändern, daß sie nicht mehr vom DB2-Server erkannt
wird. Sie sollten vor allem die Verwendung von CCSIDs mit IMPLICIT
CONTEXTUAL und IMPLICIT RIGHT-TO-LEFT vermeiden, wenn eine andere
Zeichenfolgeart verwendet werden kann. CONTEXTUAL-CCSIDs können zu
unvorhersehbaren Ergebnissen führen, wenn die SQL-Abfrage Zeichenfolgen in
Anführungszeichen enthält. Vermeiden Sie daher in SQL-Anweisungen
Zeichenfolgen in Anführungszeichen. Verwenden Sie nach Möglichkeit
überall Host-Variablen.
Wenn eine bestimmte bidirektionale CCSID Probleme hervorruft, die nicht durch das Befolgen dieser Empfehlungen korrigiert werden können, setzen Sie DB2BIDI auf den Wert NO. |
Der Datenbankmanager vergleicht Zeichendaten mit Hilfe einer Sortierfolge. Dies ist eine Reihenfolge für eine Zeichengruppe, mit der festgelegt wird, ob ein bestimmtes Zeichen vor, nach oder gleichwertig mit einem anderen angeordnet wird. Mit einer Sortierfolge kann beispielsweise angegeben werden, daß Großbuchstaben und Kleinbuchstaben gleich bewertet werden sollen.
Die Sortierfolge wird bei der Datenbankerstellung angegeben und kann später nicht mehr geändert werden.
Der Datenbankmanager ermöglicht das Erstellen von Datenbanken mit benutzerdefinierten Sortierfolgen über die API (Anwendungsprogrammierschnittstelle). Informationen zur Implementierung einer benutzerdefinierten Sortierfolgentabelle finden Sie im Handbuch Application Development Guide.
Anmerkung: | Daten aus Zeichenfolgen, die mit dem Attribut FOR BIT DATA definiert wurden, und BLOB-Daten werden mit der Binärsortierfolge sortiert. |
Wenn eine Sortierfolge definiert ist, werden alle zukünftigen Zeichenvergleiche für diese Datenbank mit dieser Sortierfolge ausgeführt. Mit Ausnahme von Zeichendaten, die mit dem Attribut FOR BIT DATA oder BLOB definiert wurden, wird die Sortierfolge für alle SQL-Vergleiche und Klauseln ORDER BY verwendet, sowie für das Erstellen von Indizes und Statistiken. Weitere Informationen zur Verwendung der Datenbanksortierfolge finden Sie im Abschnitt über Vergleiche von Zeichenfolgen im Handbuch SQL Reference.
In folgenden Fällen können Probleme auftreten:
Ein letzter Punkt, der zu beachten ist, besteht darin, daß die Ergebnisse eines Sortiervorgangs, der auf einem direkten Vergleich von Zeichencodepunkten beruht, nur mit den Ergebnissen einer Abfrage übereinstimmen, die mit einer Identitätssortierfolge geordnet wurden.
Die von Ihnen ausgewählte Datenbanksortierfolge kann sich auf die Leistung des Systems zusammengeschlossener Datenbanken auswirken. Wenn eine Datenquelle dieselbe Sortierfolge wie die zusammengeschlossene DB2-Datenbank verwendet, kann DB2 die von der Sortierfolge abhängige Verarbeitung von Zeichendaten in die Datenquelle auslagern. Verwendet eine Datenquelle eine von DB2 abweichende Sortierfolge, werden die Daten abgerufen, und die gesamte von der Sortierfolge abhängige Verarbeitung von Zeichendaten erfolgt lokal (dies kann die Leistung beeinträchtigen).
Beachten Sie die folgenden Punkte, wenn sie ermitteln wollen, ob DB2 und eine Datenquelle dieselbe Sortierfolge verwenden:
Die Sortierfolge bezieht sich auf die auf einem Server unterstützte Sprache. Vergleichen Sie die NLS-Informationen von DB2 und der Datenquelle.
Manche Datenquellen werden mit Sortierfolgen erstellt, die nicht zwischen Groß-/Kleinschreibung unterscheiden. Dadurch können von der Sortierfolge abhängige Operationen zu anderen Ergebnissen führen als in DB2.
Einige Datenquellen bieten mehrere Optionen für Sortierfolgen bzw. ermöglichen deren Anpassung.
Wählen Sie die Sortierfolge für eine zusammengeschlossene DB2-Datenbank entsprechend der Mischung der Datenquellen aus, auf welche diese Datenbank zugreift. Beispiel:
Informationen zur Einrichtung einer MVS-Sortierfolge finden Sie in den Beispielen unter der Beschreibung der API sqlecrea (Create Database) zur Erstellung von Datenbanken im Handbuch Administrative API Reference. Diese Beispiele enthalten Sortierfolgetabellen für die EBCIDIC-Codepages 500, 37 und 5026/5035.
Denken Sie nach dem Festlegen der Sortierfolge für die DB2-Datenbank daran, die Server-Option collating_sequence für jeden Datenquellen-Server zu definieren. Diese Option gibt an, ob die Sortierfolge eines gegebenen Datenquellen-Servers mit der Sortierfolge der DB2-Datenbank übereinstimmt.
Setzen Sie die Option collating_sequence auf den Wert "Y", wenn die Sortierfolgen übereinstimmen. Diese Einstellung ermöglicht dem Optimierungsprogramm von DB2, von der Sortierfolge abhängige Verarbeitung in der Datenquelle vorzunehmen, was zu einer höheren Leistung führen kann. Unterscheidet sich jedoch die Sortierfolge der Datenquelle von der in DB2, erhalten Sie möglicherweise falsche Ergebnisse erhalten. Wenn Ihr Plan z. B. Mischverknüpfungen verwendet, lagert das DB2-Optimierungsprogramm Sortieroperationen soweit möglich in die Datenquellen aus. Wenn die Datenquelle eine andere Sortierfolge hat, können die Verknüpfungsergebnisse falsch sein.
Setzen Sie die Option collating_sequence auf den Wert "N", wenn die Sortierfolgen nicht übereinstimmen. Verwenden Sie diesen Wert, wenn sich die Sortierfolgen der Datenquelle von DB2 unterscheiden oder wenn die Sortieroperationen der Datenquelle möglicherweise die Groß-/Kleinschreibung nicht beachten. In einer Datenquelle mit einer deutschen Codepage ohne Beachtung von Groß-/Kleinschreibung z. B. werden die Begriffe KARUSSELL, KaRUsSeL und karussell als identisch betrachtet. Setzen Sie die Option collating_sequence auf "N", wenn Sie nicht sicher sind, daß die Sortierfolgen der Datenquelle und DB2 übereinstimmen.
Die Datentypen für Datum und Uhrzeit werden im folgenden beschrieben. Werte für Datum und Uhrzeit können zwar in bestimmten arithmetischen Operationen und Zeichenfolgeoperationen verwendet werden und sind auch mit bestimmten Zeichenfolgen kompatibel, allerdings handelt es sich bei diesen Werten weder um Zeichenfolgen noch um Ziffern.
Datum ist ein Wert, der aus drei Teilen besteht (Jahr, Monat und Tag). Der Wertebereich für das Jahr liegt zwischen 0001 und 9999. Der Wertebereich für den Monat liegt zwischen 1 und 12. Der Wertebereich für den Tag liegt zwischen 1 und x, wobei x vom Monat abhängig ist.
Intern wird ein Datum durch eine Zeichenfolge aus 4 Byte dargestellt. Jedes dieser Byte besteht aus 2 gepackten Dezimalziffern. Die ersten zwei Byte stehen für das Jahr, das dritte Byte für den Monat und das letzte Byte für den Tag.
Die Länge einer Datumsspalte (DATE), wie im SQL-Deskriptorbereich beschrieben, beträgt 10 Byte. Dies ist die geeignete Länge für die Darstellung des Werts als Zeichenfolge.
Uhrzeit ist ein Wert, der aus drei Teilen besteht (Stunde, Minute und Sekunde) und eine Uhrzeit in der 24-Stunden-Zeiteinteilung bezeichnet. Der Wertebereich für die Stunde liegt zwischen 0 und 24. Der Wertebereich für die anderen Teile liegt zwischen 0 und 59. Wenn die Stunde 24 ist, sind die Minuten- und Sekundenangaben gleich null.
Intern wird Zeit durch eine Zeichenfolge aus 3 Byte dargestellt. Jedes dieser Byte besteht aus 2 gepackten Dezimalziffern. Das erste Byte steht für die Stunde, das zweite Byte für die Minute und das letzte Byte für die Sekunde.
Die Länge einer Zeitspalte (TIME), wie im SQL-Deskriptorbereich beschrieben, beträgt 8 Byte. Dies ist die geeignete Länge für die Darstellung des Werts als Zeichenfolge.
Eine Zeitmarke ist ein aus sieben Teilen bestehender Wert (Jahr, Monat, Tag, Stunde, Minute, Sekunde, Mikrosekunde), der einen Wert für ein Datum und eine Uhrzeit (wie oben definiert) bezeichnet, nur daß hier für die Zeit zusätzlich Mikrosekunden angegeben werden.
Intern wird die Zeitmarke durch eine Zeichenfolge aus 10 Byte dargestellt. Jedes dieser Byte besteht aus 2 gepackten Dezimalziffern. Die ersten vier Byte stehen für das Datum, die nächsten drei Byte für die Uhrzeit und die letzten drei Byte für die Mikrosekunden.
Die Länge einer Zeitmarkenspalte (TIMESTAMP), wie im SQL-Deskriptorbereich beschrieben, beträgt 26 Byte. Dies ist die geeignete Länge für die Darstellung des Werts als Zeichenfolge.
Werte mit dem Datentyp DATE, TIME oder TIMESTAMP werden intern in einer Form dargestellt, die sie für den SQL-Benutzer transparent ist. Datum, Uhrzeiten und Zeitmarken können allerdings auch als Zeichenfolgen dargestellt werden. Diese Darstellungen betreffen den SQL-Benutzer direkt, da es keine Konstanten oder Variablen mit den Datentypen DATE, TIME oder TIMESTAMP gibt. Daher muß ein Wert für Datum und Uhrzeit, der abgerufen werden soll, einer Zeichenfolgenvariablen zugeordnet werden. Die Darstellung als Zeichenfolge entspricht normalerweise dem Standardformat der Werte für Datum und Uhrzeit, die dem Landescode des Clients zugeordnet sind, sofern diese nicht durch Angabe der Formatoption "F" bei der Vorkompilierung des Programms oder beim Binden an die Datenbank überschrieben werden. Eine Liste der Zeichenfolgenformate für die verschiedenen Landescodes können Sie Tabelle 94 entnehmen.
Wenn eine gültige Zeichenfolge zur Darstellung des Werts für Datum und Uhrzeit in einer Operation mit einem internen Wert für Datum und Uhrzeit verwendet wird, wird die Zeichenfolge vor Ausführung der Operation in das interne Format für Datum, Zeit oder Zeitmarke umgesetzt. Gültige Zeichenfolgendarstellungen von Werten für Datum und Uhrzeit werden in den folgenden Abschnitten definiert.
Zur Darstellung des Datums können Zeichenfolgen verwendet werden, die mit einer Ziffer beginnen und aus mindestens 8 Zeichen bestehen. Abschließende Leerzeichen sind zulässig. Führende Nullen bei den Monats- und Tagesangaben des Datums können wegfallen.
Gültige Zeichenfolgenformate für Datumsangaben sind in Tabelle 92 aufgelistet. Für jedes Format wird der Name, eine
zugehörige Abkürzung und ein Verwendungsbeispiel angegeben.
Tabelle 92. Formate zur Darstellung des Datums als Zeichenfolge
Formatname | Abkürzung | Datumsformat | Beispiel |
---|---|---|---|
International Standards Organization | ISO | jjjj-mm-tt | 1994-10-27 |
IBM USA Standard | USA | mm/tt/jjjj | 10/27/1994 |
IBM Europäischer Standard | EUR | tt.mm.jjjj | 27.10.1994 |
Japanischer Industriestandard | JIS | jjjj-mm-tt | 1994-10-27 |
Standortabhängig (lokal) | LOC | Abhängig vom Landescode der Datenbank | -- |
Zur Darstellung der Uhrzeit können Zeichenfolgen verwendet werden, die mit einer Ziffer beginnen und aus mindestens 4 Zeichen bestehen. Abschließende Leerzeichen sind zulässig. Eine führende Null kann bei den Stundenangaben wegfallen, und die Sekunden können ganz wegfallen. Wenn Sie die Sekunden nicht angeben, wird eine implizite Angabe von 0 Sekunden angenommen. Dementsprechend ist 13.30 äquivalent zu 13.30.00.
Gültige Zeichenfolgenformate für Uhrzeitangaben sind in Tabelle 93 aufgelistet. Für jedes Format wird der Name, eine
zugehörige Abkürzung und ein Verwendungsbeispiel angegeben.
Tabelle 93. Formate zur Darstellung der Uhrzeit als Zeichenfolge
Formatname | Abkürzung | Zeitformat | Beispiel |
---|---|---|---|
International Standards Organization | ISO | hh.mm.ss | 13.30.05 |
IBM USA Standard | USA | hh:mm AM oder PM | 1:30 PM |
IBM Europäischer Standard | EUR | hh.mm.ss | 13.30.05 |
Japanischer Industriestandard | JIS | hh:mm:ss | 13:30:05 |
Standortabhängig (lokal) | LOC | Abhängig vom Landescode der Anwendung | -- |
Anmerkungen:
Zur Darstellung einer Zeitmarke können Zeichenfolgen verwendet werden, die mit einer Ziffer beginnen und aus mindestens 16 Zeichen bestehen. Die vollständige Darstellung einer Zeitmarke hat das Format jjjj-mm-tt-hh.mm.ss.nnnnnn. Abschließende Leerzeichen sind zulässig. Führende Nullen können aus der Monats-, Tages- oder Stundenangabe der Zeitmarke weggelassen werden. Mikrosekunden können vollständig abgeschnitten oder weggelassen werden. Wenn Sie Ziffern in der Mikrosekundenangabe weglassen, wird eine implizite Angabe von 0 angenommen. Dementsprechend ist 1991-3-2-8.30.00 äquivalent zu 1991-03-02-08.30.00.000000.
Zeichenfolgen für Datum und Zeitmarke dürfen nur aus Einzelbytezeichen und -ziffern bestehen.
Die Zeichenfolgen für Datums- und Zeitformate entsprechen dem Standardformat der Werte für Datum und Uhrzeit, die dem Landescode der Anwendung zugeordnet sind. Dieses Standardformat kann durch Angeben der Formatoption "F" beim Vorkompilieren oder Binden an die Datenbank überschrieben werden.
Es folgt eine Beschreibung der Ein- und Ausgabeformate für Datum und Uhrzeit:
Anmerkung: | Tabelle 94 zeigt außerdem eine Liste der Zeichenfolgeformate für die verschiedenen Landescodes. |
Tabelle 94. Datums- und Zeitformate mit Landescodes
Landescode | Lokales Datumsformat | Lokales Zeitformat | Standard- ausgabe- datums- format | Eingabe- datumsformate |
---|---|---|---|---|
355 Albanien | jjjj-mm-tt | JIS | LOC | LOC, USA, EUR, ISO |
785 Arabisch | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
001 Australien (1) | mm-tt-jjjj | JIS | LOC | LOC, USA, EUR, ISO |
061 Australien | tt-mm-jjjj | JIS | LOC | LOC, USA, EUR, ISO |
032 Belgien | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
055 Brasilien | tt.mm.jjjj | JIS | LOC | LOC, EUR, ISO |
359 Bulgarien | tt.mm.jjjj | JIS | EUR | LOC, USA, EUR, ISO |
001 Kanada | mm-tt-jjjj | JIS | USA | LOC, USA, EUR, ISO |
002 Kanada (Französisch) | tt-mm-jjjj | ISO | ISO | LOC, USA, EUR, ISO |
385 Kroatien | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
042 Tschechische Republik | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
045 Dänemark | tt-mm-jjjj | ISO | ISO | LOC, USA, EUR, ISO |
358 Finnland | tt/mm/jjjj | ISO | EUR | LOC, EUR, ISO |
389 FJR Republik Mazedonien | tt.mm.jjjj | JIS | EUR | LOC, USA, EUR, ISO |
033 Frankreich | tt/mm/jjjj | JIS | EUR | LOC, EUR, ISO |
049 Deutschland | tt/mm/jjjj | ISO | ISO | LOC, EUR, ISO |
030 Griechenland | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
036 Ungarn | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
354 Island | tt-mm-jjjj | JIS | LOC | LOC, USA, EUR, ISO |
091 Indien | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
972 Israel | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
039 Italien | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
081 Japan | mm/tt/jjjj | JIS | ISO | LOC, USA, EUR, ISO |
082 Korea | mm/tt/jjjj | JIS | ISO | LOC, USA, EUR, ISO |
001 Lateinamerika (1) | mm-tt-jjjj | JIS | LOC | LOC, USA, EUR, ISO |
003 Lateinamerika | tt-mm-jjjj | JIS | LOC | LOC, EUR, ISO |
031 Niederlande | tt-mm-jjjj | JIS | LOC | LOC, USA, EUR, ISO |
047 Norwegen | tt/mm/jjjj | ISO | EUR | LOC, EUR, ISO |
048 Polen | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
351 Portugal | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
086 VR China | mm/tt/jjjj | JIS | ISO | LOC, USA, EUR, ISO |
040 Rumänien | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
007 Rußland | tt/mm/jjjj | ISO | LOC | LOC, EUR, ISO |
381 Serbien/ Montenegro | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
042 Slowakei | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
386 Slowenien | jjjj-mm-tt | JIS | ISO | LOC, USA, EUR, ISO |
034 Spanien | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
046 Schweden | tt/mm/jjjj | ISO | ISO | LOC, EUR, ISO |
041 Schweiz | tt/mm/jjjj | ISO | EUR | LOC, EUR, ISO |
088 Taiwan | mm-tt-jjjj | JIS | ISO | LOC, USA, EUR, ISO |
066 Thailand (2) | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
090 Türkei | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
044 Großbritannien | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
001 USA | mm-tt-jjjj | JIS | USA | LOC, USA, EUR, ISO |
084 Vietnam | tt/mm/jjjj | JIS | LOC | LOC, EUR, ISO |
Anmerkungen:
|