Problem with DB2 Decimal Field

[mmacmillan]

Hi All. Hopefully someone can help us with our problem. I work on a client server application where we have a client that talks to a headless image which in turn talks to the database. Now...on the database
we have specified a column as decimal (31, 2). When our headless image trys to put a value in that column...it bombs with the following error:

AbtError: rc=-1 for '22005' in an AbtIbmCliCSDatabaseConnection at (4/3/2008 10:15:28 AM) '[SQLSTATE=22005 - [IBM][CLI Driver] CLI0112E Error in assignment. SQLSTATE=22005 [Native Error=-99999]]

Now..this just started with our upgrade to 7.x from 6.x. I believe the problem is due to changes made on the Decimal conversion code. Here is the code from 6.02:

The value that we are sending when we get the error is 794596.59. That is the value that we are sending to these methods below.

AbtDatabaseDecimalField>>put:intoRecord:parentOffset:
| numericBA |

numericBA :=
(self valueAsSQLString: obj) asByteArray.
aRecord data
abtByteArrayAt: anOffset + offset
put: numericBA
length: (self baseLength)
pad: self padChar.
aRecord valueLengthFor: self put: (numericBA size)

This code works just fine as it is padding with Nul on the right up to the size of the field.

But here is the new code:

AbtDatabaseDecimalField>>put:intoRecord:parentOffset:
| numericBA |

##PTR==##PQ79198.

numericBA := self sqlStringAsPaddedDecimalBytearray: (self valueAsSQLString: obj).

numericBA memcpyFrom: 0
to: numericBA size - 1
into: aRecord data
startingAt: aParentOffset + offset.

aRecord valueLengthFor: self put: numericBA size

As you can see...in 7.x the code changed and now the value is padded on the right with zeros instead of Nul. For some reason this breaks any insert or update to that database column.

Can someone please from Instantiations please have a look at this and fix as we have customers that are dealing with this as we speak?

Thanks in advance,

Matthew MacMillan
Checkfree is now a part of Fiserv.

[FredF]

This fix is necessary and was already included in 6.0.3
Trying to go to DB2 (i5 V5R4), for me it works up to dec(30, 2) but fails for dec(31, 2) in ScaledDecimal fromUnscaled: anInteger sign: aSign scale: aScale method
This condition is evaluated as true:
number ~= 0 ifTrue: [^ self primitiveError: PrimErrDecimalPrecisionOverflow ].
Apparently you go further than that and get an DB2 error, I don't know why.
Fred

[mmacmillan]

So then there is no fix for this problem? We upgraded from 6.02 to 7.51 so you can see that we just hit the problem. You are saying it is a
DB2 problem then? It worked just fine in 6.02. Why was this code changed in the first place? What did it fix?

If I just put back in the old code...what will happen?

Thanks a lot for your speedy replies. Our customers appreciate it

[FredF]

Hi Matthew,
To avoid confusion: I'm not from Instantiations, only another customer trying to help (and, I confess, the customer who reported the bug to IBM some years ago (in Sept 2003) which generates this correction).
The original problem submitted to IBM is 84453,300,624 and is the following one:
With:
db2 "create procedure test (in p2 dec(4), in p3 char(2)) specific test language sql begin end"
call procedure test from vast with the 'E' value as second parameter (any other character between 'A' and 'Z' is working ...), and any decimal in the first one ==> abt.exe crash (the windows process disappears without log or anything)
DB2 was DB2 windows V 7.2 fixpack 8 and VAST 6.0
Fred

[mmacmillan]

Thanks Fred! I really do appreciate your feedback. Can someone from Instantiations reading this please respond?
I am wondering what side effects will happen if I drop back to the pre 6.03 code for the put:intoRecord:parentOffset: method.

Anyone?

Thanks in advance,

Matthew MacMillan
Checkfree is now a part of Fiserv

[FredF]

Hi Matthew,
Did you see: http://www-1.ibm.com/support/docview.ws ... wg1IY43456
It seems pretty much related to "our" bug (they are also speaking of 'E' following trailing (previously missing in vast 6.0) zeroes)
Apparently a DB2 correction is necessary: perhaps you could check the fixpack level of the DB2 installation(s) with the level specified in http://www-1.ibm.com/support/docview.ws ... wg1IY43456
Fred