0

いくつかのJasperReportsを作成し、Windowsマシンで非常に正常に実行しています。この問題は、レポートがzOSオペレーティングシステムを搭載したメインフレームで実行されるように設定されたときに始まりました。

問題は、Jasperがレポートを作成するときに、データベースからテーブルのメタデータを読み取り、それに基づいてデータが来ることを期待しているように見えることです。
例：varchar（20）型の列がある場合、レポートフィールドがStringとして定義されている場合でも、Jasperは20文字だけ待機します。

これはWindows環境では発生しませんが、メインフレームでは文字エンコードはEBCDICであるため、列のメインフレームには19文字が含まれる可能性がありますが、エンコードすると23文字または24文字としてレポートに返されます。

注：この問題は、英語以外の文字でのみ発生します。

Jasperがレポートを作成しているときに、 UPDATE
AConversionBufferFullがスローされます。メインフレームのログにアクセスできないため、完全なトレースがありません。この問題は、値が約17〜20文字の場合、COUNTRY_DESCと呼ばれる1つの列のみで発生し、例外が発生します。

前述したように、メインフレームの文字セットはEBCDICですが、JDBCを介して読み取ると、Unicodeに変換されます。たとえば、EBCDICでは、単語は17文字になりますが、変換すると22文字になります。奇妙な理由で、Jasperはこのフィールドにのみ20文字を期待しています。

4

2 に答える 2

1

sun.io.ConversionBufferFullExceptionsun.io文字エンコードコンバーターによってスローされjava.io、古いバージョンのJavaのクラスを介してバブルする可能性があります。このAPIはしばらくの間非推奨になり、java.nio.charset代わりにJava 6が使用されるため、使用されなくなりました。

これは、JasperReports、JDBCドライバー、またはこれら2つで使用されるもののいずれかにおける文字変換のバグです。誤って変換されたのはメタデータ内の文字列である可能性がありますが、JDBCResultSet自体からメタデータを読み取ることとは何の関係もないと思います。

スタックトレースがないと、責任を負わせたり、回避策を考えたりするのは困難です。

于 2009-12-22T12:00:33.003 に答える
1

JasperReports自体は、データ変換やフィールド長を管理しません。これは、JDBCドライバーの問題のようです。

Sherman Jaspersoft

于 2009-12-23T19:09:24.027 に答える