Re: problem with CVS version

From: "Dave Page" <dpage(at)vale-housing(dot)co(dot)uk>
To: "Antonio Pennino" <a(dot)pennino(at)nocerainformatica(dot)net>, <pgsql-odbc(at)postgresql(dot)org>
Subject: Re: problem with CVS version
Date: 2004-07-30 13:03:17
Message-ID: E7F85A1B5FF8D44C8A1AF6885BC9A0E41A753B@ratbert.vale-housing.co.uk
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-odbc

> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Antonio Pennino
> Sent: 29 July 2004 16:33
> To: pgsql-odbc(at)postgresql(dot)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.

Responses

Browse pgsql-odbc by date

  From Date Subject
Next Message Brev Patterson 2004-07-30 17:59:35 Pg/ODBC driver connection discovery and speed
Previous Message Dave Page 2004-07-30 07:39:14 Re: problem with CVS version