DB2 Universal Database - Systemverwaltung


Zeichensätze

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.

Zeichensatz für Kennungen

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.

Definition des erweiterten Zeichensatzes für DBCS-Kennungen

In DBCS-Umgebungen umfaßt der erweiterte Zeichensatz alle Zeichen des Standardzeichensatzes plus die folgenden Elemente:

Codieren von SQL-Anweisungen

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.

CCSID-Unterstützung für bidirektionale Zeichen

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.

Spezifische CCSIDs für bidirektionale Zeichen

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.

Implementierung von Unterstützung bidirektionaler Zeichen in DB2 Universal Database

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.

Implementierung von Unterstützung bidirektionaler Zeichen in DB2 Connect

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:

  1. DB2 Connect stellt eine Verbindung zur DB2-Host-Datenbank mit CCSID 00862 her.
  2. DB2 Connect führt eine bidirektionale Layoutumsetzung der Daten aus, die gerade an die DB2-Host-Datenbank gesendet werden sollen. CCSID 62213 (bidirektionale Zeichenfolgeart 5) wird in die CCSID 62221 (bidirektionale Zeichenfolgeart 6) umgesetzt.
  3. DB2 Connect führt eine bidirektionale Layoutumsetzung der Daten aus, die von der DB2-Host-Datenbank empfangen werden. Diese Umsetzung erfolgt von CCSID 08616 (bidirektionale Zeichenfolgeart 6) in CCSID 62213 (bidirektionale Zeichenfolgeart 5).
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.

Sortierfolge

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.

Allgemeine Überlegungen

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.

Überlegungen zu zusammengeschlossenen Datenbanken

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:

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.

Werte für Datum und Uhrzeit

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

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

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.

Zeitmarke

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.

Darstellung von Werten für Datum und Uhrzeit 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.

Zeichenfolgen für das Datum

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

Zeichenfolgen für die Uhrzeit

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:

  1. In den Uhrzeitformaten ISO, EUR oder JIS ist .ss (bzw. :ss) wahlfrei.

  2. Im Uhrzeitformat USA kann die Angabe der Minuten weggelassen werden, was implizit eine Angabe von 00 Minuten bedeutet. Demnach ist 1 PM äquivalent zu 1:00 PM.

  3. Im Uhrzeitformat USA kann die Stundenangabe nicht größer als 12 sein und darf, abgesehen vom Spezialfall 00:00 AM, nicht 0 sein. Bei Verwendung des ISO-Formats mit der 24-Stunden-Zeiteinteilung gelten die folgenden Entsprechungen zwischen dem Format USA und der 24-Stunden-Zeiteinteilung:

Zeichenfolgen für Zeitmarken

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.

Hinweise für MBCS

Zeichenfolgen für Datum und Zeitmarke dürfen nur aus Einzelbytezeichen und -ziffern bestehen.

Datums- und Uhrzeitformate

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:


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:

  1. Ländern, die die standardmäßige länderspezifische Angabe C verwenden, wird der Landescode 001 zugeordnet.

  2. jjjj in der buddhistischen Zeitrechnung entspricht der gregorianischen Zeitrechnung + 543 Jahre (nur Thailand).


[ Seitenanfang | Vorherige Seite | Nächste Seite | Inhaltsverzeichnis | Index ]