Frage

Ich habe ein paar Jasperreports hergestellt und läuft sehr gut auf einem Windows -Computer. Das Problem begann, als die Berichte auf einem Mainframe mit dem ZOS -Betriebssystem ausgeführt werden sollten.

Das Problem ist: Wenn Jasper den Bericht erstellt, scheint er die Tabellenmetadaten aus der Datenbank zu lesen und basierend darauf zu erwarten, dass die Daten kommen.
Beispiel: Wenn ich eine Spalte vom Typ varchar (20) habe, wartet Jasper nur dann auf 20 Zeichen, selbst wenn das Berichtsfeld als Zeichenfolge definiert ist.

Das passiert nicht in der Windows-Umgebung, aber auf dem Mainframe ist das Zeichenkodieren eBCDIC, und so hat die Spalte möglicherweise 19 Zeichen im Mainframe, aber wenn sie codiert, kodierte sie in den Bericht als 23 oder 24 Zeichen.

Hinweis: Dieses Problem tritt nur in nicht englischen Charakteren auf.

AKTUALISIEREN
EIN ConversionBufferFull wird geworfen, wenn Jasper den Bericht erstellt, habe ich nicht die vollständige Spur, da ich nicht auf das Mainframe -Protokoll zugreifen kann. Das Problem tritt bei nur einer Spalte namens Country_DESC auf, wenn der Wert etwa 17-20 Zeichen liegt. Die Ausnahme tritt auf.

Wie ich bereits erwähnt habe, ist der auf dem Mainframe festgelegte Charakter eBCDIC, aber wenn er das JDBC durchlesen, ist es in Unicode konvertiert. Zum Beispiel in Ebcdic wird das Wort 17 Zeichen sein, aber wenn es umgewandelt wird, wird es 22. Aus irgendeinem seltsamen Grund erwartet Jasper nur 20 für dieses Feld.

War es hilfreich?

Lösung

Jasperreports selbst verwaltet weder die Datenkonvertierung noch die Feldlänge. Dies sieht nach einem Problem mit dem JDBC -Treiber aus.

Sherman Jaspersoft

Andere Tipps

sun.io.ConversionBufferFullException wird von geworfen sun.io Charaktercodierungswandler und können durchblasen java.io Klassen in älteren Versionen von Java. Diese API ist seit einiger Zeit veraltet und wird seit Java 6 - nicht mehr verwendet java.nio.charset wird stattdessen verwendet.

Es ist ein Charakterkonvertierungsfehler in Jasperreports, Ihrem JDBC -Treiber oder in den beiden verwendeten Dingen. Ich glaube nicht, dass es etwas mit dem Lesen von Meta-Daten aus dem JDBC-Ergebnis an sich zu tun hat, obwohl es sich möglicherweise um die Saiten in der Meta-Daten handelt, die falsch konvertiert werden.

Es ist schwer, die Schuld zu geben oder sich eine Arbeit ohne die Stapelspur auszudenken.

Lizenziert unter: CC-BY-SA mit Zuschreibung
Nicht verbunden mit StackOverflow
scroll top