Integer values >= 10000 is mostly corrupted

[Christian Jorgensen]

Sometimes the integer values returned by a SQL statement is corrupted. Some simple testing suggests, that the problem occurs when the value is 5 digits or more.

Running the attached sample node program will produce the following output:

ExecAsync().
SQLExecDirect(0): select * from (values int( 10000 )) as x (int_val)
SQLDescribeCol(1).
[0]sqlType[4]   colScale[0]     colPrecise[4]
SQLBindCol(1).
Select results: [{"INT_VAL":"10000/\u0019@"}]
SQLFreeStmt: stmth 3 [SQL_DROP]
SQLDisconnect: conn obj [1802f1870] handler [2]
SQLFreeConnect: conn obj [1802f1870] handler [2]

Run the sample program multiple times, and the result will sometimes be correct, but most of the times it will be corrupted.

I have tried several versions of idb-connector, but all versions have the same problem.

[Christian Jorgensen]

FYI - I tested the sample program on the same server using Node6 and db2a driver from 5733OPS LPP, and here there were no errors. So the problem is isolated to the code in idb-connector.

[Christian Jorgensen]

Another integer problem: large bigint values are chopped off, i.e. the last digits are removed.

In testv2.js sample program the value bigint( 12345678901 ) is returned as [{"BIGINT_VAL":"123456789"}]:

ExecAsync().
SQLExecDirect(0): select * from (values int( 12345 )) as x (int_val)
SQLDescribeCol(1).
[0]sqlType[4]   colScale[0]     colPrecise[4]
SQLBindCol(1).
int( 12345 ) returned as [{"INT_VAL":"123450\n"}]
SQLFreeStmt: stmth 3 [SQL_DROP]
ExecAsync().
SQLExecDirect(0): select * from (values bigint( 12345678901 )) as x (bigint_val)
SQLDescribeCol(1).
[0]sqlType[19]  colScale[0]     colPrecise[8]
SQLBindCol(1).
bigint( 12345678901 ) returned as [{"BIGINT_VAL":"123456789"}]
SQLFreeStmt: stmth 4 [SQL_DROP]
SQLDisconnect: conn obj [1802f2ef0] handler [2]
SQLFreeConnect: conn obj [1802f2ef0] handler [2]

I really hope this will be fixed soon, as the errors with this module is quite a showstopper at the moment.

[mengxumx]

Hello @chrjorgensen ,

The previous db2a driver allocates too much memory so it never chopped any data. The idb-connector reduced memory usage to get better performance.

The root cause is that DB2 reports this column with precision 4 (int) / 8 (bigint) , but to represent these values in string, it needs more than 4 / 8 characters. I will hard-code the numbers in the next version to support the minimum/maximum numbers.

[mengxumx]

The new version 1.0.12 fixed the problem. You can upgrade to this version by

npm -g update idb-connector

[Christian Jorgensen]

Hello @mengxumx

I can confirm that version 1.0.12 fixed the integer problem. Thank you for the fix!