PDA

View Full Version : JVAGATE mit Sonderzeichen in CHAR-Feldern



Seiten : [1] 2

Peet
27-08-19, 08:39
Hallo zusammen,
ich verwende JVAGATE für den Zugriff auf verschiedene ext. Datenbanken, funktioniert alles super. (Thx DB).
Jetzt ist eine Oracle-DB (FIBU) dazugekommen, funktioniert auch generell.
Die Verarbeitung habe ich in SQLRPG-Pgm's, dort connecte ich zu den DB's, Öffne Cursor, leses Sätze, schließe Cursor und schliesse die Verbindung wieder !

Mein Problem
In manchen Sätzen sind Sonderzeichen wie z.B. "%" gespeichert, und ich falle beim FETCH in meinem SQLRPG-Pgm auf die Nase, SQL-Code ist dann -969!
Mit dem DB-Tool SQuirreL funktioniert der Zugriff fehlerfrei !

Das kann doch nur bedeuten, dass ich am/in meinem SQLRPG-Pgm in Sachen "Zeichensatz" etwas "machen" muss, oder ???

Danke vorab + Vg.

Fuerchau
27-08-19, 11:22
Also "%" ist noch kein Sonderzeichen sondern bewegt sich noch im ASCII-Bereich.
Oracle speichert i.d.R. in UTF8, also Unicode.
Wenn deine Hostvariablen vom Typ "C" sind (UCS2), hast du mit Oracle keine Probleme.
Willst du die Daten im RPGLE konvertieren benötigt dein Job zur Laufzeit eine gültige CCSID!
*HEX (65535) geht da nicht mehr!!!
Dann konvertiert die Zuweisung (eval) automatisch zwischen UCS2 und deinem SBCS-Feld.
Aber Achtung: UCS => SBCS führt bei nicht konvertierbaren Zeichen zu "?".

Wichtig bei der ganzen Sache ist noch, dass du auf jeden Fall mit Parametermarkern arbeitest.
Also:

MySQL = 'Select a, b, c from OracleTab where K1=?';
execute SQL prepare Statement ….
execute SQL open MyCursor using : HostK1;

Ähnliches musst du dann auch mit Insert/Update/Delete machen, der Fetch benötigt das ja sowieso schon.

Parametermarker vereinfachen das Handing i.Ü. und beschleunigen erheblich, da nicht ständig prepared werden muss.

BenderD
27-08-19, 11:52
... same procedure as every year:
- log4j auf debug stellen
- restart des Serverprozesses
- im logfile nachsehen
- nix gefunden? mit minimalisiertem Beispiel an D*B schicken.

D*B

Peet
27-08-19, 12:06
Also "%" ist noch kein Sonderzeichen sondern bewegt sich noch im ASCII-Bereich.
Oracle speichert i.d.R. in UTF8, also Unicode.
Wenn deine Hostvariablen vom Typ "C" sind (UCS2), hast du mit Oracle keine Probleme.
Willst du die Daten im RPGLE konvertieren benötigt dein Job zur Laufzeit eine gültige CCSID!
*HEX (65535) geht da nicht mehr!!!
Dann konvertiert die Zuweisung (eval) automatisch zwischen UCS2 und deinem SBCS-Feld.
Aber Achtung: UCS => SBCS führt bei nicht konvertierbaren Zeichen zu "?".

Wichtig bei der ganzen Sache ist noch, dass du auf jeden Fall mit Parametermarkern arbeitest.
Also:

MySQL = 'Select a, b, c from OracleTab where K1=?';
execute SQL prepare Statement ….
execute SQL open MyCursor using : HostK1;

Ähnliches musst du dann auch mit Insert/Update/Delete machen, der Fetch benötigt das ja sowieso schon.

Parametermarker vereinfachen das Handing i.Ü. und beschleunigen erheblich, da nicht ständig prepared werden muss.


Danke...aber der SQL-Befehl ist fix und fertig, ich arbeite an dieser Stelle nicht mit "using"...

Peet
27-08-19, 13:10
... same procedure as every year:
- log4j auf debug stellen
- restart des Serverprozesses
- im logfile nachsehen
- nix gefunden? mit minimalisiertem Beispiel an D*B schicken.

D*B

Hallo D*B,
danke...
- log4j auf debug stellen
...das sind diese hier ???
thx.

534

BenderD
27-08-19, 13:28
bei der vorletzten Zeile den # rausmachen

Fuerchau
27-08-19, 13:53
"
ich arbeite an dieser Stelle nicht mit "using"..." ist halt häufiger ein Problem gerade bei der Verwendung von Unicode.
Das SQL-Statement selber ist meist nicht Unicode und somit könnte man nicht mit Unicodedaten im SQL arbeiten.

Dieter schreibt allerdings auch einiges ins Joblog.

Peet
27-08-19, 13:58
bei der vorletzten Zeile den # rausmachen

Danke, werde ich heute Abend testen, wenn ich alleine zugreife.
Thx.

Peet
16-04-20, 09:44
Hallo D*B
ich bin hier nun ein Stück weiter, es sind nicht (unbedingt) Sonderzeichen die zum Fehler führen.
In der Oracle DB sind die Infofelder, die der Anwender durchaus auch mit Sonderzeichen beschreibt, im Format 4000 VARCHAR.
Wenn ich ohne CAST arbeite, läuft beim ArdGate etwas über (ich habe die Fehlermeldung gerade nciht, aber irgendetwas mit Index und > 257, kann ich aber noch wieder "produzieren").
Ich habe jetzt mit CAST die Infofelder auf 256 Stellen begrenzt und komme damit dann auch erst einmal weiter.
Danke + Vg.

BenderD
16-04-20, 12:32
... hast Du die aktuelle Version, ich erinnere mich dunkel an eine Fehlerbehebung. Ansonsten wäre ein Beispiel und das log hilfreich.

D*B