Kompatiblität der CCSIDs 273 und 1141 / Probleme mit SQL

[schatte]

Hallo zusammen,

bisher war ich der Meinung, dass die CCSIDs 273 und 1141 bis auf das EURO-Zeichen nachezu Baugleich miteinander wären.

Im SQL Umfeld scheint das jedoch nicht der Fall zu sein.
Ich habe eine Tabelle CCSIDTST mit zwei Characterfeldern:

CREATE TABLE QGPL/CCSIDTST                            
(TXT1141 CHAR (10 ) CCSID 1141 NOT NULL WITH DEFAULT,
 TXT273  CHAR (10 ) CCSID 273 NOT NULL WITH DEFAULT)

Anschließend habe ich einen Datensatz eingefügt:
INSERT INTO CCSIDTST VALUES('ABC1000', 'ABC1000')

Nun ändere ich die Jobcodepage auf CCSID 1025 (RUS).

Folgendes SQL kann ich erfolgreich ausführen:

select * from CCSIDTST where TXT273 = 'ABC1000'

Eine Abfrage auf das Characterfeld mit CCSID 1141 funktioniert jedoch nicht:

select * from CCSIDTST where TXT1141 = 'ABC1000'

Man erhält folgende Joblog Meldungen:

Nachrichten-ID . . . . :   CPD4329       Bewertung  . . . . . . :   40      
Nachrichtenart . . . . :   Diagnose                                         
Sendedatum . . . . . . :   30.01.17      Sendezeit  . . . . . . :   10:39:00
                                                                            
Nachricht . . . :   Auswahl für Operator X'0001' ungültig. Ursachencode 7.  
Ursache  . . . . :  Entweder sind die Auswahloperanden miteinander oder mit
  Operator X'0001' in Auswahleintrag 3 für Auswahlart 1 nicht verträglich.  
  Welche Art von Unverträglichkeit vorliegt, ist aus Ursachencode 7         
  ersichtlich. Die Ursachencodes haben folgende Bedeutung:                  
    1 -- Vergleich von numerisch mit DBCS-Only oder Nicht-Unicode-Grafik,   
  Datum mit Nicht-Datum, Uhrzeit mit Nicht-Uhrzeit oder Zeitmarken mit      
  Nicht-Zeitmarke oder Binärzeichenfolge mit Nicht-Binärzeichenfolge.       
    2 -- Beide Operanden sind Felder variabler Länge, für die Nullwerte     
  zulässig sind.                                                            
    3 -- Der erste Operand ist kein Feld.                                   
    4 -- Der zweite oder dritte Operand ist kein Literal oder Variablenfeld.
    5 -- Der erste Operand ist kein Zeichen- oder Doppelbyte-Operand.     
    6 -- Der Operand für den Suchbegriff ist länger als das zugehörige    
  Suchziel.                                                               
    7 -- Die CCSIDs (ID des codierten Zeichensatzes) der Operanden können
  nicht so geändert werden, dass sie verträglich sind.                   
...
    13 -- XML-Operanden sind nur bei den Prädikaten NULL oder EXISTS zulässig.
    Der erste Operand ist TXT1141 mit der CCSID 1141. Der zweite Operand ist  
   HVR0001 mit der CCSID 1025. Der dritte Operand ist *N mit der CCSID 0.     
  Lautet der Operand *N, ist dieser Operand für den Operator nicht            
  erforderlich. Auswahlart 1 bedeutet Satzauswahl; Auswahlart 2 bedeutet      
  Gruppenauswahl (Group by), Auswahlart 3 bedeutet Vorgangsauswahl und        
  Auswahlart 4 bedeutet Verbindungsauswahl (Join).                           


Nachrichten-ID . . . . :   SQL0332       Bewertung  . . . . . . :   30       
Nachrichtenart . . . . :   Diagnose                                          
Sendedatum . . . . . . :   30.01.17      Sendezeit  . . . . . . :   10:39:00
                                                                             
Nachricht . . . :   Zeichenumsetzung zwischen CCSID 1141 und CCSID 1025      
  ungültig.                                                                  
Ursache  . . . . :  Es wurde versucht, eine Zeichen- oder Grafikumsetzung für
  nicht verträgliche Daten durchzuführen. Eine Umsetzung zwischen CCSID 1141
  und CCSID 1025 ist nicht definiert.                                        
    Ist eine CCSID 65535, ist die andere CCSID eine Grafik-CCSID. Die        
  Umsetzung zwischen der CCSID 65535 und einer Grafik-CCSID ist nicht        
  definiert.                                                                 
    Handelt es sich um eine Anweisung CONNECT, ist die Umsetzung zwischen der
  Standard-SBCS-CCSID des Anwendungs-Requesters und der SBCS-CCSID des       
  Anwendungsserver nicht definiert. Ist die zweite CCSID 0, wurde die        
  Standard-SBCS-CCSID des Anwendungsservers nicht zurückgegeben. Ein        
  Anwendungsserver, der kein DB2 für IBM i-Anwendungsserver ist, unterstützt  
  die CCSID 65535 möglicherweise nicht.                                       
Fehlerbeseitigung:  Sicherstellen, dass jeder Zeichen- oder Grafikvergleich,  
  jede Zeichen- oder Grafikverknüpfung und jede Zeichen- oder Grafikzuordnung
  zwischen Spalten oder Host-Variablen erfolgt, die verträgliche CCSID-Werte  
  haben.                                                                      
    Handelt es sich um eine Anweisung CONNECT, entweder die SBCS-CCSID des    
  Anwendungs-Requesters oder des Anwendungsservers ändern, damit die Umsetzung
  zwischen den CCSID-Werten definiert ist.

Getestet habe ich unter V5R3, V7R1 und V7R3.

Das sieht mir ja fast nach einem IBM Fehler aus oder hat jemand hierzu eine Idee?

Viele Grüße
Matthias

[Fuerchau]

Nein, das ist ganz normal!
CCSID's unterschiedlicher Sprachräume sind generell nicht kompatibel und werden bereits seit V2! abgelehnt. Dies liegt im Konzept der CCSID's begründet.
Möchtest du mehrere unterschiedliche Sprachen in einer Tabelle speichern bleibt dir Unicode (N[VAR]CHAR) nicht erspart.

Sprachräume sind z.B. durch ISO-8859-X definiert.

[KM]

Also wir haben V7R2 und da funktioniert's ohne Fehler.

Gruß,
KM

[schatte]

Nein, das ist ganz normal!
CCSID's unterschiedlicher Sprachräume sind generell nicht kompatibel und werden bereits seit V2! abgelehnt. Dies liegt im Konzept der CCSID's begründet.
Möchtest du mehrere unterschiedliche Sprachen in einer Tabelle speichern bleibt dir Unicode (N[VAR]CHAR) nicht erspart.

Sprachräume sind z.B. durch ISO-8859-X definiert.

Die meisten Felder sind bereits mit GRAPHIC 13488 kodiert. Keyfelder habe ich jedoch immer noch mit SBCS definiert.

Trotzdem ist doch das nicht einheitliche Verhalten zwischen 273 und 1141 nicht in Ordnung.

[Fuerchau]

Ich hatte mich auf dieses bezogen:
"Zeichenumsetzung zwischen CCSID 1141 und CCSID 1025 ungültig."
Bei 13488 gibt es keine Probleme!
Wenn du auf 273 eine Abfrage mit z.B. Umlauten und 1025 machst, gibt es ähnliche Probleme.

[schatte]

Also wir haben V7R2 und da funktioniert's ohne Fehler.

Gruß,
KM

Das ist ja interessant.
Ich habe mir nun auch zwei unterschiedliche V7R2 Maschinen gesucht.
Bei einer klappt es (TL16306) und bei der anderen nicht (TL15135).

Also schreibe ich die IBM mal an.

Danke und Gruß
Matthias

[Fuerchau]

TL16306 ist doch größer als TL15135, mach doch einen Update bevor du eine Meldung abgibst.
Wobei ich nicht weiß, wieso das ohne Meldung auf einmal funktionieren sollte. Dies führt doch zu viel größeren Problemen im Nachhinein.

[schatte]

Ich hatte mich auf dieses bezogen:
"Zeichenumsetzung zwischen CCSID 1141 und CCSID 1025 ungültig."
Bei 13488 gibt es keine Probleme!
Wenn du auf 273 eine Abfrage mit z.B. Umlauten und 1025 machst, gibt es ähnliche Probleme.

In den Alphafeldern sind nur Zeichen enthalten, die in allen EBCDIC Codepages enthalten sind. z.B. der Jobname oder der Username.
Das es Probleme gibt (Hex 3F, ...), wenn CCSID abhängige Zeichen abgefragt oder geschrieben werden, ist schon klar.

Ich wundere mich darüber, dass 273 klappt und 1141 nicht. Aber anscheinend hat die IBM hier schon irgendwas gemacht, jedenfalls in V7R2.

[KM]

Ich wundere mich darüber, dass 273 klappt und 1141 nicht. Aber anscheinend hat die IBM hier schon irgendwas gemacht, jedenfalls in V7R2.

Wir haben auch TL16306. Deshalb scheint es bei uns zu funktionieren. IBM hat da wohl wirklich schon was gemacht. Die invarianten Zeichen werden alle ganz normal angezeigt. Und die varianten Zeichen werden in der Anzeige durch etwas nicht darstellbares ersetzt. Insofern ist das schon alles korrekt so.

Gruß,
KM

[Fuerchau]

Unschön ist es insofern doch, dass inkompatible CCSID's (DB vs JOB) nun akzeptiert werden.
Dies wird unweigerlich zu Datenproblemen führen, es sei denn, dass ein Update dann auf jeden Fall ausgeschlossen wird. Man kann dann leider sehr schnell Daten fremder CCSID's unbeabsichtigt zerstören!
Dies hat eben die obige Meldung wegen inkompatibler CCSID verhindert.

Sobald mehrere CCSID's benötigt werden, also im Prinzip Mehrsprachigkeit in der DB kommt man um Unicode nicht herum. Spätestens bei Client-Anwendungen (Java, .NET) stellt das doch überhaupt kein Problem dar.
Ich weiß gar nicht, warum man immer mit aller Gewalt Unicode verhindern will um parallel deutsch und russisch in einer Tabelle zu speichern.
Langfristig tut ihr euch damit keinen Gefallen.
Ich habe einem Kunden schon mal gesagt, dass die ständigen Adressänderungen zwischen polnischen und deutschen Terminals eben in der Nichtverwendung von Unicode begründet sind.

[schatte]

Es ist ja nicht nur die eigene Anwendung.
z.B. haben wir als Primärsprache 2984 installiert. Die Systemtabellen haben dann die CCSID 28709. Wenn ich nun meinen Job auf CCSID 1153 (PLK) stelle und anschließend:
SELECT * FROM systables WHERE SYS_TNAME = 'CCSIDTST'

bekomme ich auch wieder den Fehler:
Character conversion between CCSID 28709 and CCSID 1153 not valid.

[Fuerchau]

Das ist ja genau das Problem mit den CCSID's.
Die Jobs müssen zur Laufzeit natürlich immer die passende CCSID des Systems aufweisen oder können allenfalls *HEX sein.
Die 1153 (Latin-2) ist nun mal leider nicht kompatibel zu 28709 (Chinesisch).
Ein Ändern der CCSID deines SQL-Serverjobs hat noch zusätzlich fatale folgen:
Nach Erstellung eines Result-Sets greift der ODBC/OLEDB/JDBC-Server wiederum auf die QSYS2-Objekte zu um die korrekten Felddefinitionen des Resultsets zu erfragen.
Hier scheitert der Server dann aber an der falschen CCSID.

M.a.W:
Mischungen von unterschiedlichen CCSID's auf einem System sind äußerst schwierig zu behandeln.
Die einzige Alternative ist wirklich Unicode oder entsprechende Casts in Unicode beim Select (View).
Bei Updates hast du dann ggf. schon wieder probleme, wenn du die Automatismen von .NET o.ä. verwendest, da du jeden Wert explizit in die korrekte CCSID casten musst:

select cast(My1153Field as nvarchar(nn) ...

update My1153File set My1153Field = cast(MyUnicodeValue as char(nn) ccsid 1153) ...