Re: SQLGetData/NUMERIC field in MS Access database

Tech Tip: Click here to run a free scan for Windows Errors and optimize PC performance

On Fri, 13 Jul 2007 10:46:11 -0700, "Dmitry Basko"
<dmbasko@xxxxxxxxx> wrote:

Hi,
May be someone has already seen something similar. I created a simple
file in MS Access 2003 , containing 2 columns: TEXT (9 chars), NUMERIC
(decimal). My pretty simple code has been working for years, but now
it can't read the data from the numeric column (in this particular
case) anymore : any calls like
*******
SQL_NUMERIC_STRUCT NumStr;
rc = SQLGetData(in_hsmt, (SQLSMALLINT) dp->in_offset, (SQLSMALLINT)
SQL_NUMERIC, &NumStr, sizeof(NumStr), &length);
rc = SQLGetData(in_hsmt, (SQLSMALLINT) dp->in_offset, (SQLSMALLINT)
SQL_C_DOUBLE, &d_temp, 8, &length);
rc = SQLGetData(in_hsmt, (SQLSMALLINT) dp->in_offset, (SQLSMALLINT)
SQL_C_CHAR, ch_buf, 32, &length);
******
return the same incorrect data.

If the length of the first textual column is changed (I tried
7,8,10,11 chars combinations) or if the length is still 9 characters but the
type of the second column is other than decimal (double or integer for
example), the same code works fine, all 3 calls return the same right
number (no doubt, it must work in this way).

It seems that the ODBC driver fails to perform the required conversion
of the numeric data from the second column if the fist textual column
has length of 9 chars and the second column is DECIMAL. I might be
wrong but to me it looks like a bug in ODBC/JET.

Additional info:
WINXP SP2, MDAC 2.8, Microsoft Access driver: 4.00.6304.00
MS Access 2003 (ver 11), build 5614, JET ver. 4.0

It's possible that SQL_DECIMAL behaves differently than SQL_NUMERIC
.... did you try it?

--
Bob Hairgrove
NoSpamPlease@xxxxxxxx
.