Re: 09.03.0100 cursor failures on various architectures

(2014/02/14 21:54), Heikki Linnakangas wrote:
> On 02/12/2014 12:45 PM, Christoph Berg wrote:
>> s390x has that problem, plus an additional diff for positioned-update:
>>
>> *** /«PKGBUILDDIR»/test/expected/positioned-update.out Tue Dec 17
>> 14:16:00 2013
>> --- /«PKGBUILDDIR»/test/results/positioned-update.out Wed Feb 5
>> 17:09:31 2014
>> ***************
>> *** 13,19 ****
>> 2 2
>> 3 3
>> 4 4
>> ! 105 5
>> 7 7
>> 8 8
>> 9 9
>> --- 13,19 ----
>> 2 2
>> 3 3
>> 4 4
>> ! 5 5
>> 7 7
>> 8 8
>> 9 9
>
> This is also an issue related to endianess and mismatched datatypes. The
> problem is with the SQLBindCol call. Positioned-update test does this:
>
> long colvalue;
> ...
> rc = SQLBindCol(hstmt, 1, SQL_C_LONG, &colvalue, 0, &indColvalue);
>
> And SQLBindCol does this:
>
> case SQL_C_SLONG:
> case SQL_C_LONG:
> len = 4;
> if (bind_size > 0)
> *((SQLINTEGER *) rgbValueBindRow) = atol(neut_str);
> else
> *((SQLINTEGER *) rgbValue + bind_row) = atol(neut_str);
> break;
>
> So, SQLBindPos assumes that the target variable is of type SQLINTEGER,
> when the caller indicated that it's SQL_C_LONG. My gut reaction is that
> that's bogus - if the caller said that it's of C-type long, by passing
> SQL_C_LONG, we should believe that, rather than assume that SQL_C_LONG
> means SQLINTEGER. I found a brief thread on this on the unixodbc-dev
> mailing list:
>
> http://mailman.unixodbc.org/pipermail/unixodbc-dev/2005-March/000396.html
>
> The same author raised the issue also on the psqlodbc mailing list:
>
> http://www.postgresql.org/message-id/flat/4224F80D(dot)2080103(at)kkcsm(dot)net#4224F80D(dot)2080103@kkcsm.net
>
> Microsoft has a table of SQL_C_* codes and which C types they correspond
> to (http://msdn.microsoft.com/en-us/library/ms714556%28v=vs.85%29.aspx)
> but that's not taking into account other operating systems where the
> widths of C integer types are different. We didn't explicitly discuss in
> that psqlodbc mailing list thread if it's sane that SQL_C_LONG means a
> 32-bit integer regardless of how wide the C "long" type actually is.

I don't think so.
Where do you find references to OS native C types in ODBC's spec?
ODBC uses its own SQL types in its spec and each SQL_C_xxxxxxx
stands for one of them not a native one.

For 32bit integers, use SQL_C_LONG (SQLINTEGER).
For 64bit integers, use SQL_C_BIGINT (SQLBIGINT).
There's no type named SQLxxLONGxx.

I can see the following line in sqlext.h provided by Microsoft or unixODBC.

#define SQL_C_LONG SQL_INTEGER /* INTEGER
*/

It means that those driver manager think SQL_C_LONG means SQLINTEGER.
What meaning does it have to take different way from the driver manager
whose APIs ODBC applications call?

regards,
Hiroshi Inoue

--
I am using the free version of SPAMfighter.
SPAMfighter has removed 5285 of my spam emails to date.
Get the free SPAMfighter here: http://www.spamfighter.com/len

Do you have a slow PC? Try a Free scan
http://www.spamfighter.com/SLOW-PCfighter?cid=sigen