Re: 09.03.0100 cursor failures on various architectures

(2014/02/26 17:51), Heikki Linnakangas wrote:
> On 02/26/2014 03:19 AM, Inoue, Hiroshi wrote:
>> (2014/02/26 1:56), Heikki Linnakangas wrote:
>>> 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?
>
> SQL_C_xxx is a Microsoft-only extension, so it's not guaranteed to work
> with all SQL/CLI implementations. In practice, unixODBC defines
> SQL_C_xxx too, so in practice an application using them will work.
>
> I think you're advocating for this:
>
> SQLINTEGER        lEmpID;
> ...
> SQLBindCol(hStmt, 1, SQL_C_LONG, (SQLPOINTER) &lEmpID, sizeof(SQLINTEGER),
>        &pIndicators[0]);
>
>  From a readability point of view, IMHO that's just bizarre. The
> SQLBindCall call is claiming to the driver that the variable is of type
> "long", by specifying SQL_C_LONG. But in reality, the variable is of
> type SQLINTEGER. You can argue that SQL_C_LONG doesn't mean that the
> variable is of type "long", but "SQLINTEGER", but that's just bizarre.
> The name SQL_C_LONG very clearly says "long",just like SQL_C_SHORT says
> "short".

> It works on Windows, because sizeof(long) == sizeof(SQLINTEGER) on
> Windows, and it works with unixODBC because unixODBC defines SQL_C_LONG
> as 32-bits regardless of the actual width of "long".

The ODBC spec clearly mentiones that SQL_C_LONG corresponds to
SQLINTEGER from the first. Why do you often skip SQLINTEGER?
It's a result that Microsoft, unixODBC or iODBC defines SQLINTEGER
as 32-bit integers. The problem for unixODBC or iODBC was whether
SQLINTEGER means 32-bits or 64-bits.

 > But it's not a good
> way to write an application. Why use the ODBC extension SQL_C_LONG
> instead of the SQL_INTEGER type code specified by SQL/CLI? SQL_INTEGER
> is more clear, and as a bonus, it also complies with SQL/CLI.

Aren't you forgetting ODBC is very old?
Though ODBC and sql/cli are closely related, ODBC is older than
sql/cli. When ODBC was introduced more than 20 years ago,
Microsoft didn't have 32-bit OS yet. That's why SQLINTEGER was
was denoted as *long int* not *int*. It meant 32-bit integrs for
both their working 16-bit OS and coming 32-bit OS.
Of cource the spec was only for 16/32bit. There was no guarantee
how the 64-bit spec would be in the future. At the time pretty many
people expected that int in future 64-bit OSes would be 64-bit integers.
So I don't surprize even if SQLINTEGER means 64-bit integers sometime
somewhere. But I don't believe SQL_C_LONG stands for the type other than
SQLINTEGER. Please tell me where I can find such a fact.

Now int still means 32-bit integers in many 64-bit platforms. People
still needs 32-bit integers as well as 64-bit integers. So ODBC also
needed 32-bit integers.

> So while the combination of SQL_C_LONG type code and SQLINTEGER variable
> works, I would not recommend that. The SQL_INTEGER type code and
> SQLINTEGER variable combination is more clear.
>
>> 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.
>
> ODBC is a superset of SQL/CLI [1]. An application written for SQL/CLI
> works with ODBC libraries and drivers. But not the other way round; an
> application that's written to the ODBC spec does not necessarily work
> with other SQL/CLI implementations.

Though you emphasize ODBC is a superset, ODBC was not a superset
of sql/cli from the first. In the first place SQL/CLI didn't exist
when ODBC was introduced. Of cource SQL_C_XXXX was not an extension
of sql/cli spec then. You can't find SQL_C_XXXX because SQL_C_XXXX
is a C-specific concept and maybe sql/cli shrinked the spec so as
to avoid language-specific concept. As a result the spec uses the
same notations SQL_xxxx for different kind of concepts. ODBC uses
different notations for different kind of concepts.
Which do you prefer?

When ODBC was introduced more than 20 years ago, working OSs of
Mirosoft was 16-bit ones. 32-bit integers must have been denoted
as *long int*. They used SQL_C_LONG because *long* was the most
portable data type which means 32-bit integers then.

Now I'm examining what SQLINTEGER means in SQL/CLI spec though
it may be an old one.
Hmmm, could you please tell me SQLINTEGER is a 32-bit integer,
64-bit one or platform-dependent one on 64-bit platforms?
I find a line
    SQLINTEGER long  Length of buffers for column data and ...
Is it right in the latest spec?

regards,
Hiroshi Inoue