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
|
Список | 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 по дате отправления: