Most probably it needs a "flag" to indicate that the ODBC must work in
Unicode, and then dynamic link to *W functions if this flag is set. I
think ODBC drivers since 2002+/- should have this set of APIs, but I
had never used ODBC in my life... :)
It seems, that Driver Manager automaticaly performs conversions on
non-unicode driver. See
http://web.datadirect.com/resources/odbc/unicode/odbc-driver.html
( and
http://web.datadirect.com/resources/odbc/unicode/char-background.html )
"If the driver is a non-Unicode driver, it cannot understand W function
calls, and the Driver Manager must convert them to ANSI calls before
sending them to the driver."
Also it seems to me, that when you call ANSI version of ODBC API
functions, then you receive data in ANSI encoding.
If it is so, then it is always safe use ansitoutf8() (or UTF8Encode())
on receved data.
L> But also in this case we will get UTF-16 widestrings (in Windows) not
L> UTF-8, does not ?
That's not important, you get unicode in the specified by the API
format, then SQLConnector fills information in the expected target
format (WideString, UTF8String over AnsiString, Raw bytes...).
In Windows we get UTF-16, in Linux/UNIX we get UTF-8
So it is so, that in Windows is "widestring=UTF-16" and in Linux/UNIX is
"widestring=UTF-8" string ?
(So there is different meaning of widestring type on different OSeses ?
I am only Windows developer, so I have no understanding of others OSeses
;-))
-Laco.
_______________________________________________
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
