Re: problem with CVS version - Mailing list pgsql-odbc

From Dave Page
Subject Re: problem with CVS version
Date
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E41A753B@ratbert.vale-housing.co.uk
Whole thread Raw
In response to problem with CVS version  ("Antonio Pennino" <a.pennino@nocerainformatica.net>)
Responses Re: problem with CVS version
List pgsql-odbc

> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Antonio Pennino
> Sent: 29 July 2004 16:33
> To: pgsql-odbc@postgresql.org
> Subject: Re: [ODBC] problem with CVS version
>
>
> Identical result i have with ms-access, perhaps are wrong the
> arguments? I have take the idea from here:
>
> http://publib.boulder.ibm.com/infocenter/db2v8luw/
>        index.jsp?topic=/com.ibm.db2.udb.doc/ad/c0008616.htm

Yeah - sounds good, but on further investigation, that's an ODBC 3.51
thing. I've added it to CVS anyway (#ifdef (ODBCVER >= 0x0351) of
course), but the DM still doesn't try to set it, even with the driver
compiled as 3.51 :-(.

I also considered the option of checking the DB encoding and setting
conn->unicode = 0 if it's not unicode, but then realised that's not a
good idea because it'll prevent the server recoding other charactersets
to unicode on the fly.

What happens if you explicitly call SQLConnectA rather than SQLConnect
in your application? Or, as Janet suggested, bind to the column as
SQL_C_CHAR even if it's SQL_WVARCHAR?

Regards, Dave.

pgsql-odbc by date:

Previous
From: "Dave Page"
Date:
Subject: Re: problem with CVS version
Next
From: Brev Patterson
Date:
Subject: Pg/ODBC driver connection discovery and speed