Re: problem with CVS version

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(at)roguewave(dot)com http://www.roguewave.com

> -----Original Message-----
> From: Dave Page [mailto:dpage(at)vale-housing(dot)co(dot)uk]
> Sent: Thursday, July 29, 2004 12:46 AM
> To: Antonio Pennino; pgsql-odbc(at)postgresql(dot)org
> Subject: Re: [ODBC] problem with CVS version
>
>
>
>
> > -----Original Message-----
> > From: pgsql-odbc-owner(at)postgresql(dot)org
> > [mailto:pgsql-odbc-owner(at)postgresql(dot)org] On Behalf Of
> Antonio Pennino
> > Sent: 28 July 2004 19:45
> > To: pgsql-odbc(at)postgresql(dot)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
>