Re: unixODBC, PostgreSQL 7.3 + ODBC V3 drivers?

From: Nick Gorham <nick(at)easysoft(dot)com>
To: Hiroshi Inoue <Inoue(at)tpf(dot)co(dot)jp>
Cc: Alain Picard <Alain(dot)Picard(at)memetrics(dot)com>, Peter Harvey <pharvey(at)codebydesign(dot)com>, pgsql-odbc(at)postgresql(dot)org, claudio(dot)natoli(at)memetrics(dot)com
Subject: Re: unixODBC, PostgreSQL 7.3 + ODBC V3 drivers?
Date: 2003-02-05 09:49:14
Message-ID: 3E40DE1A.4030603@easysoft.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

Hiroshi Inoue wrote:
> Alain Picard wrote:
>
>>>>>>>Hiroshi Inoue writes:
>>
>>Hiroshi> I checked unixODBC sources a little. ISTM unixODBC checks
>>Hiroshi> the existence of the function SQLColAttributes and if it
>>Hiroshi> exists, it calls SQLColAttributes( not SQLColAttribute)
>>Hiroshi> passing through the Field Identifier parameter.
>>Hiroshi> Is it right ?
>>
>>I _think_ that's right, but I'll leave it to Nick or Peter to confirm.

Ok, this is my take.

SQLColAttributes is a ODBC 2 call, its depreciated in ODBC 3, so if a
app calls SQLColAttributes, the DM will call SQLColAttributes in the
driver (if it exists), otherwise it will call SQLColAttribute.

If the app calls SQLColAttribute and the driver supports SQLColAttribute
then its passed into the driver. If the driver only has SQLColAttributes
then the DM will map some ODBC 3 values to their ODBC 2 version (if they
differ).

Its made a bit stranger in that the value that SQLGetFunctions returns
is the SAME for the two calls, so the only way the DM can tell which the
driver has if by the functions exported by the shared lib.

Does that help ?

--
Nick Gorham
Easysoft Limited http://www.easysoft.com

In response to

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Ocke Janssen 2003-02-05 11:53:58 Re: OpenOffice and PostgreSQL: query with inner join
Previous Message Alain Picard 2003-02-05 03:10:41 Re: unixODBC, PostgreSQL 7.3 + ODBC V3 drivers?