Fehlerhafte Sonderzeichenumsetzung

[Fuerchau]

Na also, geht doch;-)!

[Domeus]

Hallo.

Jetzt habe ich doch nochmal eine Nachfrage:

In einem anderen Programm haben wir folgenden SQL Befehl genutzt um zu prüfen ob die Variable daten273 Sonderzeichen beinhaltet:

D datenein        S            300A   CCSID(1208)    
D daten273        S            300A   CCSID(273)     

exec sql select cast(:datenein as varchar(300) ccsid 273)   
            into :daten273                          
            from SYSIBM.SYSDUMMY1 fetch first 1 row only;      
IF sqlcode = 335;                                   
  //Sonderzeichen vorhanden
ENDIF;

Ich frage mich nun ob man diese Prüfung nicht auch durch die Umwandlung mit ifs_read_utf8 mit erledigen kann? Aber egal welche Variablen ich kombiniere weder ifs_read_utf8 noch ifs_read usw. spucken hier einen anderen sqlcode als 0 aus.

Könnte man trotzdem irgendwie auslesen, falls z.B: beim ifs_read (ohne _utf8) eine Umsetzung fehlerhaft ist oder muss ich dafür immer die andere Prüfung nehmen?

Gruß
Sebastian

[Fuerchau]

Per Definition gibt es keinen Fehler bei einer Umsetzung von UTF8 oder UTF16 (1200) in eine beliebige andere CCSID, da bei ungültigen Zeichen grundsätzlich das "?" eingesetzt wird.
Dies wurde halt so festgelegt und ist auch im Windows-Umfeld so.

Wenn man per ODBC in die DB2 übertragen will und die Tabelle eine Single-CCSID hat, 273, 1141, 870, usw., gibt es eine Einstellung im Treiber, dass keine ungültigen Zeichen zugelassen werden (Default).
Dies trifft z.B. bei CCSID 273 das "€"-Zeichen, da dort das Zeichen nicht definiert ist.
Hier muss man dazu erwähnen, dass i.d.R. in ODBC-Zugriffe mit "String" umgegangen wird und diese sind seit 1998 grundätzlich UTF16. Einzig in byteorientierten Sprachen wie C/C++ kann man noch mit Singlebyte-char-Arrays arbeiten.
Man spart sich daher das Umwandeln von Strings in byte-Arrays, außer bei der Verwendung von UTF8.
Bei der Erkennung von ungültigen Zeichen wird der Insert/Update dann abgelehnt.