Edson Carlos Ericksson Richter wrote:
Is this the latest driver (7.5.xxx)? I've seen a message in MaxDB list about bug in JDBC driver concerning decimal precision and nasty roundings...
I use the latest available driver 7.5.01.00. The classes are from march 2004, so maybe the bug isn't fixed in this version.
Seems we have to apply option 3 to default platform and use option 2 in sapDB/maxDB.
regards, Armin
My2c,
Richter
Em Qua, 2004-08-18 �s 15:55, Armin Waibel escreveu:
Hi Jason, Stuart,
it's an really nasty issue! If I apply 'option 3'
else if ((value instanceof BigDecimal) && (sqlType == Types.DECIMAL || sqlType == Types.NUMERIC)) { ps.setObject(index, value, sqlType, ((BigDecimal) value).scale()); }
sapDB/maxDB does not pass NumberAccuracyTest:
Testcase: testBigDecimal took 0,015 sec FAILED expected:<67.3456> but was:<67.0> junit.framework.AssertionFailedError: expected:<67.3456> but was:<67.0> at org.apache.ojb.broker.NumberAccuracyTest.testBigDecimal(NumberAccuracyTest.java:55)
seems that in that case maxDB has problem with scale setting. If I use option 2
else if(sqlType == Types.DECIMAL || sqlType == Types.NUMERIC) { ps.setObject(index, value); }
All tests pass. What to do? - Apply option 3 to default Platform and override #setObjectForStatement(...) in maxDB to use option 2 or old behavior? - Apply option 2 to default Platform and override Sybase Platform #setObjectForStatement(...) and use option 3 for Sybase? - Apply option 2 for DB2 and option 3 for Sybase?
regards, Armin
Jason Mihalick wrote:
Armin Waibel wrote:
I local apply your patch to PlatformDefaultImpl and run the test-suite against sapDB/maxDB with success. So, what do the experts think about it? ;-) Apply this patch to PlatformDefaultImpl?
I haven't corresponded yet with the other folks that replied to my post, but I do think since other folks are seeing the problem in Sybase and other platforms that it does indeed belong in PlatformDefaultImpl. Also, if you look at the JavaDoc for setObject...
Option 1 -> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html#setObject(int,%20java.lang.Object,%20int)
vs.
Option 2 -> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html#setObject(int,%20java.lang.Object)
OR
Option 3 -> http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html#setObject(int,%20java.lang.Object,%20int,%20int)
it's pretty evident that either the 2nd or 3rd option is the proper choice here. That brings up the question, which is the best choice? Even though I know that option 2 works for DB2, it does seem like option 3 is the saftest route to go. The JavaDoc is pretty explicit for option 3 about the handling of DECIMAL data types. So after having reviewed this in more detail, my vote would be to go with the patch as suggested by Stuart Heriot in the following post:
http://nagoya.apache.org/eyebrowse/[EMAIL PROTECTED]&msgNo=13981
This posting, incidentally, did receive some feedbadk from other users saying that they had seen the same problem.
Do all of them agree apply the patch in PlatformDefaultImpl? Does it solve the sybase problem too?
Yes, I think the concensus is to go with Option 3 above.
Thanks, Jason
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
