> Hi,
>
> Just ran option 2 on sybase and it works! I admit not what I was expecting
> but can't complain.
>
> So feel free to put option 2 into default implementation and leave the
> sybase implementation as it is.
>
Patched version (option 2) of PlatformDefaultImpl is in CVS now. Thanks Jason, Stuart for your patience.
Hope I will never have to read the words "BigDecimal and truncation" in a post again ;-)
regards, Armin
> Cheers > Stuart
-----Original Message----- From: Jason Mihalick [mailto:[EMAIL PROTECTED] Sent: Thursday, 19 August 2004 12:05 PM To: Armin Waibel; [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Patch: DB2 BigDecimal problem (truncation occurs and data is lost)
Armin Waibel wrote:
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.j
ava: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?
Perhaps Stuart will give us feedback on Sybase, but based on your current findings my vote would now be for your second choice above:
- Apply option 2 to default Platform and override Sybase Platform #setObjectForStatement(...) and use option 3 for Sybase
If Sybase passes with option 2 in PlatformDefaultImpl, then you could just modify PlatformDefaultImpl and you're done! If Stuart doesn't respond, though, your option above seems like the safest choice to me.
Thanks for spending the time on this!
-- Jason
---------------------------------------------------------------------------- ------------------------------------ Prior messages leading up to this message are below...
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#setO
bject(int,%20java.lang.Object,%20int)
vs.
Option 2 ->
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html#setO
bject(int,%20java.lang.Object)
OR
Option 3 ->
http://java.sun.com/j2se/1.4.2/docs/api/java/sql/PreparedStatement.html#setO
bject(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]&m
sgNo=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]
