FFI doesn't map WideStrings to C strings, because there's no unified way
to do it. What you have to do is to encode the WideString to a
ByteString (using a TextConverter), but you should consult the OpenDBX
manual about this.
On Mar 6, 2011, at 10:35 04PM, Levente Uzonyi wrote:
> On Sun, 6 Mar 2011, Mariano Martinez Peck wrote:
> (pine still can't quote your mail)
> FFI doesn't map WideStrings to C strings, because there's no unified way to do it. What you have to do is to encode the WideString to a ByteString (using a TextConverter), but you should consult the OpenDBX manual about this.
"The statement stored in the stmt parameter must be a valid statement understood by the receiving database server and it should be terminated by a \0 character. Some backends support multiple statements per query, which can be tested by calling odbx_get_option().
The length parameter must contain the length of the statement in bytes without the terminating \0 character. If variable sized character sets like UTF-8 are used, the same rule applies. This function doesn't support the wide character type (wchar_t) which uses two or four bytes per character. If you feed 0 (zero) as length parameter to the function, it will calculate the size of the statement on its own."
It's guess it's pretty much up to the user to figure out how to use the right encoding for the backend in question.
From the POV of providing a low-overhead solution, I guess that is an ok decision, and at least it's honest about it.
From a user POV though, it's a pretty strong argument for switching to an API which handles it transparently :)
I mean, why on earth would use use an abstract interface if you have to know intricate details about how to access each backends encoding in order to do queries/pass strings correctly?