-
Kompatiblität der CCSIDs 273 und 1141 / Probleme mit SQL
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:
Code:
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:
Code:
select * from CCSIDTST where TXT273 = 'ABC1000'
Eine Abfrage auf das Characterfeld mit CCSID 1141 funktioniert jedoch nicht:
Code:
select * from CCSIDTST where TXT1141 = 'ABC1000'
Man erhält folgende Joblog Meldungen:
Code:
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
-
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.
-
Also wir haben V7R2 und da funktioniert's ohne Fehler.
Gruß,
KM
-
Zitat von 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.
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.
-
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.
-
Zitat von KM
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
-
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.
-
Zitat von 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.
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.
-
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
-
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.
-
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.
-
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) ...
Similar Threads
-
By Der Gute in forum IBM i Hauptforum
Antworten: 10
Letzter Beitrag: 09-04-02, 15:36
-
By Günter Majewski in forum IBM i Hauptforum
Antworten: 1
Letzter Beitrag: 24-02-02, 17:03
-
By HELROHA in forum IBM i Hauptforum
Antworten: 2
Letzter Beitrag: 29-01-02, 14:58
-
By Flappes in forum IBM i Hauptforum
Antworten: 3
Letzter Beitrag: 30-08-01, 16:54
-
By Winni in forum IBM i Hauptforum
Antworten: 4
Letzter Beitrag: 30-03-01, 07:29
Tags for this Thread
Berechtigungen
- Neue Themen erstellen: Nein
- Themen beantworten: Nein
- You may not post attachments
- You may not edit your posts
-
Foren-Regeln
|
Erweiterte Foren Suche
Google Foren Suche
Forum & Artikel Update eMail
AS/400 / IBM i
Server Expert Gruppen
Unternehmens IT
|
Kategorien online Artikel
- Big Data, Analytics, BI, MIS
- Cloud, Social Media, Devices
- DMS, Archivierung, Druck
- ERP + Add-ons, Business Software
- Hochverfügbarkeit
- Human Resources, Personal
- IBM Announcements
- IT-Karikaturen
- Leitartikel
- Load`n`go
- Messen, Veranstaltungen
- NEWSolutions Dossiers
- Programmierung
- Security
- Software Development + Change Mgmt.
- Solutions & Provider
- Speicher – Storage
- Strategische Berichte
- Systemmanagement
- Tools, Hot-Tips
Auf dem Laufenden bleiben
|
Bookmarks