Re: 09.03.0100 cursor failures on various architectures

(2014/02/26 1:56), Heikki Linnakangas wrote:
> On 02/25/2014 05:13 PM, Hiroshi Inoue wrote:
>>> >1. Most applications are written with the assumption that SQL_C_LONG
>>> >means the native C data type "long". That's clearly what SQL_C_LONG was
>>> >supposed to mean when the ODBC specification was written, and that's
>>> >what Microsoft's sample code does.
>>> >
>>> >2. That's*not*  how psqlODBC or unixODBC interprets it. With unixODBC,
>>> >you should use the C data type "SQLINTEGER" with SQL_C_LONG.
>>> >
>>> >3. For maximum portability, an application should avoid using SQL_C_xx.
>>> >Instead, always use SQL_INTEGER or SQL_BIGINT, with an SQLINTEGER or
>>> >SQLBIGINT variable, and cast to native C types.
>>> >
>>> >We should document this somewhere, like in the FAQ..
>> Unfortunately I'm not happy with your summary.
>>
>> My point is simple.
>> Use ODBC data type variables instead of native C data ones when calling
>> ODBC APIs.
>
> Hmm, isn't that the same as my point 3?
>
> I was thinking of something like below for the docs:
>
> ----
> Don't use SQL_C_xxx. They are not part of the SQL/CLI specification, and
> hence not reliably portable across platforms.

Why does using SQL_C_XXXX lose portablity?
Even though SQL/CLI is a standard, ODBC also has been a (defact?)
standard which is older than CLI and widely used.
They are different standard.
We should begin a project e.g. pgsqlcli when we are to stop
using SQL_C_XXXX.

 > Instead, use the ODBC
> variable data types, like SQLINTEGER and SQLBIGINT, and the
> corresponding type codes (e.g. SQL_INTEGER and SQL_BIGINT).
>
> For example, the following code is not portable:
>
> long        empID;
> ...
> SQLBindCol(stmt, 1, SQL_C_LONG, (SQLPOINTER) &empID,
>      sizeof(long), &indicator);
>
> Instead, do this:
>
> SQLINTEGER  empID;
> ...
> SQLBindCol(stmt, 1, SQL_INTEGER, (SQLPOINTER) &empID,
>      sizeof(SQLINTEGER), &indicator);

Though the code works well, the code is wrong as an ODBC application
in principle.
The code works as expected simply because SQL_INTEGER has the same
value as SQL_C_LONG has fortunately.

> And if necessary, cast to the C type:
>
> long lEmpID = (long) empID;
>
>
> SQL_C_LONG, SQL_C_SLONG and SQL_C_ULONG in particular are known to be a
> problem,

I see no problem except the naming which should have been SQL_C_INTEGER.

regards,
Hiroshi Inoue



--
I am using the free version of SPAMfighter.
SPAMfighter has removed 5330 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