I am developing a German-Thai-Dictionary-Software for Windows 98/Me and
Windows 2000/XP. The database with the stuff in thai and german is an MDB
and thus in UNICODE.
The Windows 2000/XP-version of the product works fine.
But in the Windows 98/Me-version appears a problem. Because the program uses
UNICODE internaly (which all works fine as well), I use parameterized
SQL-Statements to change, add and retrieve data from the database. The code
for theses operations is almost the same and works fine for adding or
In code, it looks about the following:
SQLBindParameter( [...], SQL_PARAM_INPUT, SQL_C_WCHAR, SQL_WCHAR, [...] );
SQLExecDirect( [...] );
I have to use parameters, because I am on Windows 98 and can not use the
SQLExecDirectW - functions, and for passing a string to the -A - functions I
had to first convert the thai-strings to ANSI, which would corrupt them. So
I have to transfer the UNICODE (WCHAR) strings somehow directly to the
database, that is why I am using parameters. This scenario works fine for
the INSERT and UPDATE statements, and the unchanged thai-strings are added
or updated in the database. But retrieving data with the SELECT statement
does not work. The statement is something like:
SELECT * FROM db WHERE thai LIKE ?
- with ? being replaced by the UNICODE thai search string.
What I am getting is the whole content of the database. But this scenario
works fine on Windows 2000/XP systems.
Does anybody have an idea, what the problem could be, how to solve it, or
does anybody have an different approach for making ODBC accept my WCHAR
parameters and for making ODBC using it for the SELECT statement?
Could it be, that the string is internaly (in the driver) converted from
UNICODE to ANSI while executing the SELECT statement and so maybe being
replaced by nothing or spaces? Is it possible that this happens only with
the SELECT statement and not with the INSERT and UPDATE statements (because
they are working)?
Thanks a lot in advance!!
Laurents C. R. Meyer, Software Developer, Germany, Berlin