FreeTDS Development Group

["ou liu" <ou AT qbt.com>]

Thanks for your replies which did answer my question.

 

We are porting codes from Win32 to Unix using the Mainsoft's Visual MainWin
so we have the UNICODE support on the Unix.

The Visual MainWin didn't support the ADO which we used quite a lot in our
code. We have to simulate those Connections/Commands/Recordsets by
ourselves.

What we are doing is to write classes with the same name and internally call
the ODBC APIs or the DBMS native APIs. Those classes will have the same
interfaces as provided by the Microsoft so our source code (in C++) didn't
need be changed.

 

We have a stored procedure in the Server side which had a in-out parameter
with type of nvarchar(10). Normally in the ADO we do:

_variant_t vBSTR = "Hello"; // The Visual MainWin will support this
MSspecific compiler feature 

pCommand->CreateParameter(L"", adBSTR, adParamInputOutput, 20, vBSTR);

 

The CreateParameter will cause our ADO simulation code internally store an
ASCII string based on the vBSTR. (A WideCharToMultiByteChar call which
support by the Visual MainWin) Later on when the stored procedure is
executed, we will call the SQLBindParameter and passed the data in. We will
do a MultiByteCharToWideChar call before we passed the data back to the
users of our ADO simulation code since they are expecting the UNICODE
return.

 

So I was wondering whether I can just pass a UNICODE buffer straightly to
the FreeTDS ODBC driver to save the time for char set transformation. In
fact, this simulation code is first coded and tested on the win32 and then
move the unix platform. On the Win32, we are using the SQL Server ODBC
Driver provided by the MS and we can use SQL_C_WCHAR and get back UNICODE
straightly in our buffer.

 

Of course, it was just a whim of mine, sorry to bother you guys with this.

 

Regards

Ou