View Full Version : Suchen nach Umlauten
Die Codepages kannst du getrost vergessen, da 037 (USA-Englisch) zwischen 5250 und Datenbank ja korrekt passt, selbst wenn die DB 65535 hat.
Du kannst allerdings auch die DB-CCSID auf 037 per CHGPF ändern, dann sollte es eigentlich gehen.
Wichtig ist da nun eher, deinen SQL zu berichtigen.
Irgendwie wird wohl den 'Nürnberg' in 'N\ffrnberg' übersetzt. Wobei "\ff" eigentlich Hex(FF) gemeint ist und das wirst du nie finden (oder ist das nur eine Anzeige im Debugger ?).
Auch wegen Dieters Hinweis emfehle ich dringend Parametermarker!!!
Desweiteren:
Hast du für dein C++-Programm UNICODE definiert ?
Dann musst du auch über die ODBC-Konfig den SQL-String als Unicode verwenden.
Verwendest du ADO-Objekte oder native SQL-Routinen (SQLExecute, SQLConnect, CLI) ?
Wenn Du mit Parametermarkern arbeitest, kannst du den Parametertyp dann auch auf WCHAR setzen.
Ansonsten musst du in deinem Programm den SQL-String auf char[xx] anpassen und die Werte in Singlebyte konvertieren (Makro W2A).
Besser ist jedoch die Verwendung der ADO-Klassen.
andreaspr@aon.at
29-03-10, 14:44
hast du schon probiert das gleiche phänomen auch bei anderen tabellen und unterschiedlicher CCSID auftritt?
zumindest testhalber würde ich das auch mit parameter probieren, denn diese sollten die konvertierungen automatisch vornehmen!
hast du schon probiert das gleiche phänomen auch bei anderen tabellen und unterschiedlicher CCSID auftritt?
zumindest testhalber würde ich das auch mit parameter probieren, denn diese sollten die konvertierungen automatisch vornehmen!
Ist mit Parametern das 'Casting' gemeint?
Das habe ich schon probiert.
Aber nochmal, nicht dass wir uns misverstehen.
Ich tippe den Select per Hand in eine ODBC SQL Tool ein.
Ich verwende also zum Testen keine C++ Programmierung.
andreaspr@aon.at
29-03-10, 16:36
nein, mit parametern ist was ganz anderes gemeint. schau dir mal den link den ich anfangs gepostet hab genauer an.
zuerst dein sql-string:
tab = "select * from tab where sp1 = ?"
und dann ein parameterobjekt, welches für das "?" eingesetzt wird.
das machst du aber nur in einem selbst programmierten programm (c++, c#, ...)
das heißt du verwendest also ein nicht selbst geschriebenes pgm um dein select abzusetzen? wenn ja, wie heist dieses pgm?
Ich habe das jetzt mit V5R4 und einer Tabelle mit CCSID 65535 ausprobiert.
Beim Select gibt es absolut keine Probleme, die Daten werden korrekt gefunden und angezeigt.
Es gibt aber ein CCSID-Problem.
Ich denke, du hast keine andere Chance als
a) die CCSID der PF zu korrigieren
oder
b) eine View mit Casting auf die korrekte CCSID anzulegen
... die CCSID der Tabelle ist da m.E. Banane, wenn da was faul ist, werden keine Sätze (oder die falschen gefunden). Dieses Problem hier muss auf der Strecke Frontend Treiber CCSID des Database Dämons liegen - und zusätzlich muss da auch noch ein Bug/Inkompatibilität im Spiel sein; entweder sollte da ein SQL Code zurückkommen (Statement wird invalid) oder eben SQL Code 100 (nix gefunne).
D*B
Ich habe das jetzt mit V5R4 und einer Tabelle mit CCSID 65535 ausprobiert.
Beim Select gibt es absolut keine Probleme, die Daten werden korrekt gefunden und angezeigt.
Es gibt aber ein CCSID-Problem.
Ich denke, du hast keine andere Chance als
a) die CCSID der PF zu korrigieren
oder
b) eine View mit Casting auf die korrekte CCSID anzulegen
CREATE TABLE VSART
(
DATE_CRE TIMESTAMP,
DATE_UPD TIMESTAMP,
D_LEISTER VARCHAR(12),
NAME VARCHAR(50),
TXT VARCHAR(254),
USER_CRE VARCHAR(10),
USER_UPD VARCHAR(10),
VERKEHRZWG VARCHAR(1),
VERKEHRZWG2 VARCHAR(2),
VERKEHRZWG_INL VARCHAR(1),
VERKEHRZWG_INLE VARCHAR(1),
VERSANDART VARCHAR(3) NOT NULL,
MANDANT INTEGER DEFAULT 0
) CCSID 1252;
Wir haben nun versucht eine Tabelle anzulegen, die die korrekte Codepage hat. Leider geht das nicht, da der Token bzw. der Bezeichner hinter CCSID nicht erkannt wird.
SELECT character_set_name from sysibm.syscharsets
zeigt keine der Codepages an, die wir auf Windowsseite haben.
Das stimmt.
Auf der AS/400 sind nur Codepages der AS/400.
Also z.B. 273 für Deutsch, 037 für Englisch usw.
Eigentlich ist die Syntax:
CREATE TABLE VSART
(
DATE_CRE TIMESTAMP,
DATE_UPD TIMESTAMP,
D_LEISTER VARCHAR(12) CCSID 273,
NAME VARCHAR(50) CCSID 273,
TXT VARCHAR(254) CCSID 273,
USER_CRE VARCHAR(10) CCSID 273,
USER_UPD VARCHAR(10) CCSID 273,
VERKEHRZWG VARCHAR(1) CCSID 273,
VERKEHRZWG2 VARCHAR(2) CCSID 273,
VERKEHRZWG_INL VARCHAR(1) CCSID 273,
VERKEHRZWG_INLE VARCHAR(1) CCSID 273,
VERSANDART VARCHAR(3) CCSID 273 NOT NULL,
MANDANT INTEGER DEFAULT 0
)
Wobei SQL-Tables per Default IMMER die CCSID des Jobs (ggf. die Default-CCSID aus Language) bekommen.
*HEX muss explizit angegeben werden bzw. ergibt sich aus dem Typ BINARY.
Alternativ wäre da noch Unicode:
MYFIELD [var]GRAPHIC(nn) CCSID 13488
andreaspr@aon.at
01-04-10, 07:51
Falls du immer noch nicht weitergekommen bist, könntest du auch ein DB-Monitoring starten. Dort siehst du dann wie der Wert der Where-Klausel auf der Seite der DB2 aussieht, nachdem er via ODBC übertragen wurde.
Falls du immer noch nicht weitergekommen bist, könntest du auch ein DB-Monitoring starten. Dort siehst du dann wie der Wert der Where-Klausel auf der Seite der DB2 aussieht, nachdem er via ODBC übertragen wurde.
Zunächstmal weiss ich natürlich nicht, wie ein DB-Monitoring zu starten ist, aber ich kann das an meinen Kunden weitergeben.
Problem ist nur, dass die DB2 ja gar keine Datei im Zugriff hat, da der Select ja gar nicht ausgeführt wird.
Wir haben das im ODBC Treiber tracen lassen und dort ist der Select schon kaputt. Nicht klar ist, ob dieser Trace vor oder nachdem Übertragen zu iSeries getraced wird.
Was ich etwas komisch finde ist, dass die Umlaute in den Feldinhalten ja korrekt angezeigt werden.
Also ein SELECT * FROM TABELLE zeigt die Umlaute. Ein INSERT oder UPDATE geht. NUR wenn der Umlaut in der WHERE CLAUSE ist, geht es nicht.
Egal bei welcher Tabelle.
Ich habe mit unserer Applikation getestet und mit einem SQL Tool. Ich bin dabei das noch mit TOAD auszuprobieren.