Re: MAC OSX copy_and_convert_field bug for SQL_W_CHAR

Поиск
Список
Период
Сортировка
От Dave Page
Тема Re: MAC OSX copy_and_convert_field bug for SQL_W_CHAR
Дата
Msg-id E7F85A1B5FF8D44C8A1AF6885BC9A0E4CC35F4@ratbert.vale-housing.co.uk
обсуждение исходный текст
Ответ на MAC OSX copy_and_convert_field bug for SQL_W_CHAR  ("Joel Kiger" <kiger.joel@cimcor.com>)
Ответы Re: MAC OSX copy_and_convert_field bug for SQL_W_CHAR  ("Joel Kiger" <kiger.joel@cimcor.com>)
Список pgsql-odbc

> -----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.

В списке pgsql-odbc по дате отправления:

Предыдущее
От: "Joel Kiger"
Дата:
Сообщение: MAC OSX copy_and_convert_field bug for SQL_W_CHAR
Следующее
От: Fernando Garcia
Дата:
Сообщение: Problema con mi BD