Обсуждение: 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? Joel Kiger
> -----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.
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
> -----Original Message----- > From: pgsql-odbc-owner@postgresql.org > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of Joel Kiger > Sent: 20 October 2005 19:01 > To: Dave Page; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] 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. > Err, right - That's definitely not the right fix, but if it help you out for now... I've just tried a quick compile on Panther, and Unicode definitely isn't supported (there is no sqlucode.h for example), though I see that Tiger does have a newer iODBC which does have that header. It also needs to link with libiodbcinst (for SQLGetPrivateProfileString/SQLWritePrivateProfileString). Peter, I'm assuming that either no-one uses iODBC, or that this is a Mac specific thing. Is there a painless way to get autoconf to add the library if needed? Finally, I'm getting warnings about multiple definitions of some MD5 functions (I guess it's finding them in libpq, as that's where they were borrowed from). I guess that might not be an issue at all if the libpq exports are cleaned up in the future, but in the meantimeI don't think there's an actual problem anyway (I'm sure Peter or Tom will correct me if I'm wrong about that :-p )/ I can't look at this for at least a couple of weeks unfortunately though. Regards, Dave.