Suchen nach Umlauten

[andreaspr@aon.at]

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!

[chs]

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]

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?

[Fuerchau]

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

[BenderD]

... 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

[chs]

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.

[Fuerchau]

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