Re: problem with CVS version
От | Janet Borschowa |
---|---|
Тема | Re: problem with CVS version |
Дата | |
Msg-id | D486606E7AD20947BDB7E56862E04C39BDC6ED@cvo1.cvo.roguewave.com обсуждение исходный текст |
Ответ на | problem with CVS version ("Antonio Pennino" <a.pennino@nocerainformatica.net>) |
Список | pgsql-odbc |
Hi, The driver manager maps ODBC API calls with unicode drivers as shown below. Please note that this is why the trace file shows calls to SQLDriverConnectW, etc. The SQL Server ODBC driver is a unicode driver. You may want to read the Microsoft ODBC Programmer's Reference for more information about programming in the presence of a unicode driver (its available online from Microsoft's website) and that may help you solve your problem. From my reading of the docs, it looks like if SQLDescribeCol is returning SQL_WVARCHAR you should not have any problem binding that column with SQL_C_CHAR and retrieving the data. If you are, then there is a bug in the driver OR there is a problem with the codesets in use on the server and/or the client which prevents the wchar data from being converted to char data. Sorry I can't help more but I don't have the time to debug the problem. ---------------------------------------------------------------------------- ------------------------ Unicode Drivers Whether a driver should be a Unicode driver or an ANSI driver depends entirely on the nature of the data source. If the data source supports Unicode data, the driver should be a Unicode driver. If the data source only supports ANSI data, the driver should remain an ANSI driver. A Unicode driver must export SQLConnectW in order to be recognized as a Unicode driver by the Driver Manager. A Unicode driver must accept Unicode functions (with a suffix of W) and store Unicode data. It can also accept ANSI functions, but is not required to. (The Driver Manager does not pass an ANSI function call with the A suffix to the driver, but converts it to an ANSI function call without the suffix and then passes it to the driver.) A Unicode driver must be able to return result sets in either Unicode or ANSI, depending on the application's binding. If an application binds to SQL_C_CHAR, the Unicode driver must convert SQL_WCHAR data to SQL_CHAR. The driver manager will map SQL_C_WCHAR to SQL_C_CHAR for ANSI drivers but does no mapping for Unicode drivers. Note When determining the driver type, the Driver Manager will call SQLSetConnectAttr and set the SQL_ATTR_ANSI_APP attribute at connection time. If the application is using ANSI APIs, SQL_ATTR_ANSI_APP will be set to SQL_AA_TRUE, and if it is using Unicode, it will be set to a value of SQL_AA_FALSE. This attribute is used so that the driver can exhibit different behavior based on the application type. The attribute cannot be set by the application directly, and it is not supported by SQLGetConnectAttr. If a driver exhibits the same behavior for both ANSI and Unicode applications, it should return SQL_ERROR for this attribute. If the driver returns SQL_SUCCESS, the Driver Manager will separate ANSI and Unicode connections when Connection Pooling is used. ---------------------------------------------------------------------------- ------------------------ ======================== Janet Borschowa Software Engineer, Database Products Rogue Wave Software, a QUOVADX(tm) Division (541) 753-1931 FAX: (541) 757-4630 mailto:borschow@roguewave.com http://www.roguewave.com > -----Original Message----- > From: Dave Page [mailto:dpage@vale-housing.co.uk] > Sent: Thursday, July 29, 2004 12:46 AM > To: Antonio Pennino; pgsql-odbc@postgresql.org > Subject: Re: [ODBC] problem with CVS version > > > > > > -----Original Message----- > > From: pgsql-odbc-owner@postgresql.org > > [mailto:pgsql-odbc-owner@postgresql.org] On Behalf Of > Antonio Pennino > > Sent: 28 July 2004 19:45 > > To: pgsql-odbc@postgresql.org > > Subject: Re: [ODBC] problem with CVS version > > > > > If the connection is made using SQLConnectW, SQLDriverConnectW or > > > SQLBrowseConnectW, > > > > I am *sure* : i not call unicode API. > > OK. > > > Ok, is a problem of the driver manager. > > The MDAC update not solve the problem. > > Yes, I think it is the DM. I just tried using the Ansi ODBC > Test program with the SQL Server driver. It called the > Unicode functions as well... > > odbcte32 828-170 ENTER SQLDriverConnectW > HDBC 003A17D8 > HWND 00040396 > WCHAR * 0x1F7A9D2C [ -3] "******\ 0" > SWORD -3 > WCHAR * 0x1F7A9D2C > SWORD 2 > SWORD * 0x00000000 > UWORD 1 <SQL_DRIVER_COMPLETE> > > odbcte32 828-170 EXIT SQLDriverConnectW with > return code 1 > (SQL_SUCCESS_WITH_INFO) > HDBC 003A17D8 > HWND 00040396 > WCHAR * 0x1F7A9D2C [ -3] "******\ 0" > SWORD -3 > WCHAR * 0x1F7A9D2C > SWORD 2 > SWORD * 0x00000000 > UWORD 1 <SQL_DRIVER_COMPLETE> > > DIAG [01000] [Microsoft][ODBC SQL Server > Driver][SQL Server]Changed database context to 'uhlive'. (5701) > > > > The database is not unicode: > > > > firedell:/etc/postgresql# psql -l > > > > List of databases > > Name | Owner | Encoding > > -----------+----------+----------- > > dbrete | postgres | SQL_ASCII > > firedell | postgres | SQL_ASCII > > template0 | postgres | SQL_ASCII > > template1 | postgres | SQL_ASCII > > > > One table (with varchar also) is read ok, the other 4 no! > > > > The difference with SQL Server is that it has separate types > for unicode/non-unicode data (nvarchar/varchar) which can be > mixed in the same table. I don't fully understand what the > possible side effects might be yet, but what if we only set > conn->unicode if the connection is made to a unicode database > AND the driver tries to call SQL*ConnectW? > > Comments anyone? > > > Why Protocol=6.4 when i have set it to 7.x? the server is 7.2.x > > 7.2.x uses the 6.4 protocol. That's normal :-) > > Regards, Dave. > > ---------------------------(end of > broadcast)--------------------------- > TIP 7: don't forget to increase your free space map settings >
В списке pgsql-odbc по дате отправления:
Следующее
От: "Mario Soto"Дата:
Сообщение: please help me with Postgresql odbc column bytea problem