Re: MAC OSX copy_and_convert_field bug for SQL_W_CHAR

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(at)postgresql(dot)org
[mailto:pgsql-odbc-owner(at)postgresql(dot)org]On Behalf Of Dave Page
Sent: Thursday, October 20, 2005 8:58 AM
To: Joel Kiger; pgsql-odbc(at)postgresql(dot)org
Subject: Re: [ODBC] MAC OSX copy_and_convert_field bug for SQL_W_CHAR

> -----Original Message-----
> From: pgsql-odbc-owner(at)postgresql(dot)org
> [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of Joel Kiger
> Sent: 20 October 2005 14:47
> To: pgsql-odbc(at)postgresql(dot)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