I has not too much luck with version 08.01.0005, but however by commenting
out #define HAVE_LOCALE_H 1 in config.h it does seem to be owrking for the
time being, at least with ASCII characters.
Thanks for your help.
-----Original Message-----
From: pgsql-odbc-owner@postgresql.org
[mailto:pgsql-odbc-owner@postgresql.org]On Behalf Of Dave Page
Sent: Thursday, October 20, 2005 8:58 AM
To: Joel Kiger; pgsql-odbc@postgresql.org
Subject: Re: [ODBC] MAC OSX copy_and_convert_field bug for SQL_W_CHAR
> -----Original Message-----
> From: pgsql-odbc-owner@postgresql.org
> [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Joel Kiger
> Sent: 20 October 2005 14:47
> To: pgsql-odbc@postgresql.org
> Subject: [ODBC] MAC OSX copy_and_convert_field bug for SQL_W_CHAR
>
> I am currently using Postgre 8.0 with the 8.00.0102 ODBC
> driver with IODBC
> 3.52.2. I can not get SQLGetData to return any valid data
> when the Ctype is
> SQL_W_CHAR (SQL_C_CHAR workds fine). At line 887 of
> convert.c (for (i = 0,
> j =0; ptr[i]; i++)) I believe I found a bug dealing with the
> byte order of a
> Mac. The variable pre is point to the following data:
>
> 0xb015f0: 0x0000 0x0039 0x0000 0x0039 0x0000 0x0039 0x0000
> 0x0039
>
> Basicaly "9999" in 2 byte unicode (Note that Macs are 4 byte unicode).
> Since ptr is a const char* it never goes into the for
> statement to copy the
> data. This is the case for numeric fields in the database I
> can only assume
> character fields have a similiar issue. Has any one else
> seen this problem?
Not sure about that specific problem, but a lot of time has gone into
fixing unicode recently. Please try the latest snapshot build
08.01.0005.
Regards, Dave.
---------------------------(end of broadcast)---------------------------
TIP 6: explain analyze is your friend
