dragokranjcec
-
Posts
5 -
Joined
-
Last visited
Content Type
Profiles
Forum
Events
Featured Visualizations
Knowledge Base
Documentation (PDF Downloads)
Blog
Documentation (Test Area)
Documentation
Dr. Jaspersoft Webinar Series
Downloads
Posts posted by dragokranjcec
-
-
I have a database accessed through ODBC driver and JDBC-ODBC Bridge. Date fields from my database map to ODBC type:
SQL_TYPE_DATE=91, 10, 0, SQL_NULLABLE=1
(this is from MS ODBC Test utility)
These date fields are displayed normally in ODBC query tool, e.g. AQT:
Name Type Length NullsdatKnj DATE 10 YBut, when I import fields using JDBC-ODBC bridge, date fields get type java.lang.Date, and of course compiler gives error:
java.lang.ClassNotFoundException: java.lang.Date
Is this a problem in JDBC driver or in JasperReports / iReport?
-
It turned out that solution is:
new String($F{fieldname}.getBytes("Cp1250"), "cp852")
however illogical it is.
-
The problem is not in iReport (or, more correctly, jasperReports), but it is not in JDBC either.
From JDBC driver I get "correct" data - they are really in CP852. I mean, JDBC driver is not converting to Unicode, so my problem is not related with your link.
What I need is just conversion of (some) string data columns, which came from database, in iReport, so that they are displayed in Windows CP1250.
Strangely, solution like:
new String($F{nPaket}.getBytes("cp852"), "Cp1250")
where nPaket is field name, does'nt work - it converts, but wrong!
-
I have a data stored in code page 852. How can I display it properly on Windows with iReport?
I am accessing datasource through JDBC-ODBC bridge. Can I do code page conversion in iReport and how?
Date field of java.lang.Date type
in Products
Posted
No, I did not define field as java.lang.Date. Problem was in ODBC driver.
SQL_TYPE_DATE is defined by ODBC standard as 10 character field with format YYYY-MM-DD. My ODBC driver was returning these values as 8 character field (without '-') and JDBC driver was confused and "invented" type java.lang.Date.
AQT was smart enough to interpret non-standard date format correctly, but JDBC driver wanted strict standard format.