Anmelden

View Full Version : Sonderzeichenproblem beim Schreiben in i5-Tabelle (z.B. €)



Karlchen50
19-08-14, 15:57
Hallo Forum,

ich habe eine DotNet-Anwendung. Diese erhält Daten aus unterschiedlichen Quellen und soll diese in eine oder mehrere i5-Tabellen schreiben.
Eines der Sonderzeichen ist zum Beispiel das Euro-Symbol (€).
Die CCSID der Zieltabellen ist jeweils 273.
Zum Speichern verwende ich die Update-Methode eines DBDataAdapter-Objektes. Dieses Verfahren funktioniert generell außer bei bestimmten Sonderzeichen.

Versuche ich, einen Datensatz zu speichern, der dieses Zeichen enthält, erhalte ich die Fehlermeldung:

Der Datenwert des Befehlsparameters [4] '' konnte aus anderen Gründen als einem Signaturübereinstimmungsfehler oder Datenüberlauf nicht konvertiert werden.

InnerException:
CWBZZ5014 Der Wert des Parameters "00005" konnte nicht in den Hostdatentyp umgesetzt werden.
CWBNL0107 - 4 Byte umgesetzt, 1 Fehler beim Beginn an Position 0 (scp=13488 tcp=273 siso=1 pad=0 sl=4 tl=20) gefunden
CWBNL0107 - 2 Byte umgesetzt, 1 Fehler beim Beginn an Position 0 (scp=1202 tcp=273 siso=1 pad=0 sl=2 tl=20) gefunden

Verwendet wird IBMDA400-provider
Sowohl
ForceTranslation=0
als auch
ForceTranslation=65535 (=Default)
brachten irgendwelche Änderungen.

Da ich die CCSID der Zieltabellen nicht ändern kann, wäre es mein Ziel, alle nicht umsetzbaren Zeichen als '?' darzustellen.

(Ein ähnliches Problem in diesem Forum hat:
Sonderzeichen können im SSIS-Paket auf SQL2008 nicht zur AS400 übertragen werden (http://newsolutions.de/forum-systemi-as400-i5-iseries/threads/19243-Sonderzeichen-können-im-SSIS-Paket-auf-SQL2008-nicht-zur-AS400-übertragen-werden) )

Ich habe jetzt den ganzen Tag recherchiert und experimentiert und bin für jede Hilfe dankbar.


<!-- title / author block -->

Fuerchau
19-08-14, 16:25
Wie der Fehler schon beschreibt, die scp (SourceCodePage) wird hier als 13488, also UCS2/Unicode ausgewiesen. Da sind halt nicht alle Zeichen konvertierbar.
Nun werden Zeichenfelder immer als String und somit als UCS2 in .NET (ebenso auch in Java u.v.a.) gespeichert.
Du musst also nun (leider) eine Konvertierungsroutine schreiben, die aus einem String alle ungültigen Zeichen extrahiert bevor du die Update-Methode anwenden kannst.
Aber eigentlich ist es nicht ganz so schlimm, wenn du nur westeuropäische Zeichen erlaubst. Dann ist nur das €-Zeichen ungültig.

Karlchen50
20-08-14, 13:07
Vielen Dank für die Antwort.
Die Konvertierung kann DotNet übernehmen (muss auch allgemeiner gefasst sein, da ich nicht weiß, welche Zeichen auf mich zukommen).
Beste Ergebnisse erziele ich mit diesem Code:


Encoding enc = Encoding.GetEncoding("IBM273", newEncoderReplacementFallback("?"), newDecoderReplacementFallback("?"));
String strOut = enc.GetString(enc2.GetBytes("ABcabc12â^°²³{[]}~µ€@"));

//liefert: ABcabc12â^°²³{[]}~µ?@

(Da wo jetzt das "Kreuzchen im Kästchen" steht, sind zwei eckige Klammern im Original)

Karlchen50
20-08-14, 13:21
Korrektur:
String strOut = enc.GetString(enc.GetBytes("ABcabc12â^°²³{http://newsolutions.de/forum-systemi-as400-i5-iseries/newreply.php?do=postreply&t=19256}~µ€@"));

Fuerchau
20-08-14, 14:14
Ich wusste gar nicht, dass .NET auch EBCDIC kann.
Liefert der Encoder da nicht dann EBCDIC, das du wieder in ANSI zurückwandeln musst?
Aber dass lässt sich ja regeln.