Yup,

it happens also in Sybase but not in all driver versions or better said not in all 
driver builds, it can happen that two different builds of the same version deliver 
different results.

No Problems on Oracle9i or MySQL 4.x

Would be great if the problem could be patched.

cheers
Danilo

Hi,

This is not just a DB2 problem. Same error occurs using Sybase. I had a
similar discussion with Armin on this a couple of months ago and have applied a
patch to PlatformDefaultImpl.setObjectForStatement() originally in rc5 but now also
in 1.0 (see below).


It would be helpful if this or something like it made it into future
releases whether in the Sybase implementation or the default implementation
I'm not concerned.


Thanks Stuart


/* * @see Platform#setObject(PreparedStatement, int, Object, int) */ public void setObjectForStatement(PreparedStatement ps, int index, Object value, int sqlType) throws SQLException { if ((value instanceof String) && (sqlType == Types.LONGVARCHAR)) { String s = (String) value; ps.setCharacterStream(index, new StringReader(s), s.length()); } // PATCH for BigDecimal truncation problem. else if ( (value instanceof BigDecimal) && (sqlType == Types.DECIMAL || sqlType == Types.NUMERIC)) { ps.setObject(index, value, sqlType, ((BigDecimal)value).scale()); } // END BigDecimal patch. else { ps.setObject(index, value, sqlType); } }

-----Original Message-----
From: Jason Mihalick [mailto:[EMAIL PROTECTED]
Sent: Tuesday, 10 August 2004 4:05 AM
To: [EMAIL PROTECTED]
Subject: Patch: DB2 BigDecimal problem (truncation occurs and data is
lost)


Brian/Thomas/Armin:

Attached is a patch that I talked to Thomas about many, many months ago. I am working on upgrading our project from OJB 1.0RC4 to the 1.0.0 release and I noticed that this problem is still there, so I am posting my work around now (sorry for the delay). In short, there is a problem that I noticed when using OJB against DB2 where the digits to the right of the decimal point are truncated when storing BigDecimals. I traced the problem down to the org.apache.ojb.broker.platforms.PlatformDefaultImpl.setObjectForStatement method. The problem is the call it makes on line 227 (as the code exists today in CVS):

    ps.setObject(index, value, sqlType);

If I remember correctly, the Javadoc for this method in the JDBC API documentation doesn't guarantee that precision is preserved. After I found this, I stopped cursing at IBM (sorry IBM ... but sometimes you do deserve it! ;-).

To fix the problem I took the safe way out and implemented the attached patch in org.apache.ojb.broker.platforms.PlatformDB2Impl. It *may* be more appropriate to implement in PlatformDefaultImpl, I'm not sure. You guys make the call. One thing that is interesting, however, is that both HSQL and Postgresql DO NOT exhibit the same problem (but I think they technically did not follow the spec). If you need me to try to dig up the Javadoc, let me know.

I hope this attachment makes it through to the list. If not, let me know and I will post it inline.

Thanks,
Jason Mihalick

P.S. - Hi Brian! I am the guy that talked to you for quite a while right after the 'An Evolution from SQL to OJB to Hibernate (TS-1748)' session at JavaOne. I commented about how much we like the PB API, and we were wondering when 1.0 was going to be released (and you mentioned that you had just released it the night before!). It was great meeting you and keep up the great work! I hope we meet again. I wonder if you wouldn't mind sending me an e-mail with your e-mail address as I would like to keep in touch since we obviously share an interest in Persistence mechanisms?





--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to