Einschränkungen

#### Search Results

Search

# Einschränkungen

- Einschränkungen bei Db2-Datentypen

- Einschränkungen bei Db2-Statements

- Einschränkungen bei der statischen Vorbereitung

- Einschränkungen bei der dynamischen Vorbereitung

## Einschränkungen bei Db2-Datentypen

- Umwandlung von DATE und TIME in CHAR

- Abruf von Zeitstempeldaten mit einer Genauigkeit von mehr als neun

- Abruf von Zeitstempeldaten mit Zeitzone

- Unterschied im Rundungsmechanismus für Fließkomma-Datentyp

### Umwandlung von DATE und TIME in CHAR

Beim Umwandeln einer Spalte vom Datentyp `DATE` und `TIME` in `CHAR` hat das Datumsformat, das sich aus der Funktion ergibt, immer das ISO-Format. Das Datumsformat in der Datei `db2.properties` wird nicht berücksichtigt. Dies ist auf eine Einschränkung des Db2 JDBC-Treibers zurückzuführen. Für JCC-Pakete wird die Pre-Compiler-Option DATE/TIME auf ISO gesetzt. Das Standardverhalten der CHAR-Funktion wird von der Pre-Compiler-Option DATE/TIME beeinflusst, die Vorrang vor den DECP-Optionen hat. Sie können den zusätzlichen Parameter in der `CHAR`-Funktion zum Ändern des `DATE`/`TIME`-Formats verwenden.

    CHAR(CURRENT DATE) /* RESULT FORMAT EXAMPLE:
    2023-05-01 CHAR(CURRENT TIME) /* RESULT FORMAT EXAMPLE: 01.01.01

### Abruf von Zeitstempeldaten mit einer Genauigkeit von mehr als neun

Beim Abruf von Zeitstempeldaten werden die Daten in einem standardmäßigen JDBC-Format mit einer Genauigkeit von bis zu neun abgerufen. Dies ist auf eine Einschränkung des Db2 JDBC-Treibers zurückzuführen. Die Umwandlung des Ergebnisses in `CHAR` löst das Problem.

    CURRENT TEMPORAL BUSINESS_TIME /* RESULT EXAMPLE:
    2011-02-28-01.01.01.123456789 CHAR(CURRENT TEMPORAL BUSINESS_TIME) /* RESULT
    EXAMPLE: 2011-02-28-01.01.01.123456789012 CURRENT TIMESTAMP(12) /* RESULT
    EXAMPLE: 2023-04-25-11.06.11.292553363 CHAR(CURRENT TIMESTAMP(12)) /* RESULT
    EXAMPLE: 2023-04-25-11.06.11.292553363769

### Abruf von Zeitstempeldaten mit Zeitzone

Beim Abrufen von Daten aus einer `TIMESTAMP WITH TIMEZONE`-Spalte werden die Daten in einem Standard-JDBC-Format ohne Zeitzone abgerufen. Der zurückgegebene Wert wird um den Unterschied zwischen der Zeitzone des Spaltenwerts und der Standardzeitzone angepasst.

Dies ist auf eine Einschränkung des Db2 JDBC-Treibers zurückzuführen. Die Umwandlung des Ergebnisses in `CHAR` löst das Problem.

    SELECT TIMESTAMP_W_TIMEZONE_COLUMN FROM ... /* RESULT EXAMPLE:
    2012-02-29-05.03.59.100000 SELECT CHAR(TIMESTAMP_W_TIMEZONE_COLUMN) FROM ... /*
    RESULT EXAMPLE: 2012-02-29-07.03.59.100000+02:00

### Unterschied im Rundungsmechanismus für Fließkomma-Datentyp

Wenn Sie Daten aus einer Spalte vom Typ `FLOATING POINT` auswählen und die Daten mehr als zwölf Ziffern haben, ist die Rundungsregel anders als bei Natural for Db2 (NDB). Daher kann der Wert der letzten Ziffer vom NDB-Ergebnis abweichen.

    /*
    Result with NDB STDDEV SALARY = .9742432961021595E 04 /* Result with NDZ STDDEV
    SALARY = .9742432961021594E 04 /* Result with NDB STDDEV SALARY =
    9742.432961021595 /* Result with NDZ STDDEV SALARY = 9742.432961021594

## Einschränkungen bei Db2-Statements

Die folgenden Natural/Db2-SQL-Statements werden derzeit von Natural for Db2 for zIIP (NDZ) nicht unterstützt, da die JDBC-Treiber sie nicht nativ unterstützen. Sie werden in den kommenden NDZ-Versionen verfügbar sein.

- `CONNECT TO`

- `GET DIAGNOSTICS`

## Einschränkungen bei der statischen Vorbereitung

- SET CURRENT DECFLOAT MODE = :HV1 bricht mit SQL-Fehler -104 ab

- SQL-Statement zum Setzen globaler Variablen schlägt bei der statischen Vorbereitung fehl

- Der SENSITIVE DYNAMIC-Cursor wechselt während der statischen Vorbereitung des Programms zu SENSITIVE STATIC

- FORWARD ONLY Cursor wechselt während der statischen Vorbereitung des Programms zu SENSITIVE STATIC

### SET CURRENT DECFLOAT MODE = :HV1 bricht mit SQL-Fehler -104 ab

Das SQL-Statement `SET CURRENT DECFLOAT MODE = :HV1` bricht während der statischen Vorbereitung mit SQL-Fehler -104 ab. Dies ist auf einen Fehler in der IBM SQLJ-Anpassung und in `BIND` zurückzuführen. Alternativ funktioniert das Statement problemlos, wenn statt der Host-Variablen ein Schlüsselwort oder ein Literal angegeben wird.

### SQL-Statement zum Setzen globaler Variablen schlägt bei der statischen Vorbereitung fehl

Das SQL-Statement zum Setzen der Werte für globale Variablen schlägt bei der statischen Vorbereitung mit der Meldung `Unsupported statement` (nicht unterstütztes Statement) fehl. Dies ist auf die SQLJ-Anpassung und das `BIND`-Verhalten zurückzuführen.

### Der SENSITIVE DYNAMIC-Cursor wechselt während der statischen Vorbereitung des Programms zu SENSITIVE STATIC

Während des statischen Vorbereitungsvorgangs wird der Cursortyp `SENSITIVE DYNAMIC` in `SENSITIVE STATIC` geändert. Die Nutzung von `SENSITIVE DYNAMIC` wird derzeit entwickelt. Sie wird in der nächsten NDZ-Version verfügbar sein.

### FORWARD ONLY Cursor wechselt während der statischen Vorbereitung des Programms zu SENSITIVE STATIC

Während des statischen Vorbereitungsvorgangs wird der Cursortyp `FORWARD ONLY` in `SENSITIVE STATIC` geändert, wenn eine Positionsaktualisierung für ein Rowset erfolgt. Dies ist darauf zurückzuführen, dass JDBC Rowsets nicht nativ unterstützt.

## Einschränkungen bei der dynamischen Vorbereitung

- Cursor-Sensitivität

### Cursor-Sensitivität

Die `SENSITIVE DYNAMIC`-Cursortypen, STATIC und ASENSITIVE, werden in den Cursortyp geändert, der in der JDBC-Eigenschaft `cursorSensitivity` in der Datei `Db2.properties` angegeben ist. Der Standardwert ist `STATIC`. Weitere Einzelheiten zur Eigenschaft `cursorSensitivity` finden Sie in der IBM-Dokumentation.

### On this page

- Einschränkungen bei Db2-Datentypen
- Einschränkungen bei Db2-Statements
- Einschränkungen bei der statischen Vorbereitung
- Einschränkungen bei der dynamischen Vorbereitung