[unixODBC-support] Unicode Support for UCS-2 databases

[Nick Gorham]

Ingmar Koecher [ NETIKUS.NET ltd ] wrote:
>
>> They don't use wchar_t, unsigned short [] is fine to hold the 
>> text, you 
>> just need a small bunch of functions to work on it as required.
>>     
>
> OK, that's what I did (unsigned short). However, I "discovered" a
> compiler option for gcc, that allows you to set the size of "wchar_t" to
> be 2 bytes. I have no experience with it yet, but activating it allows
> me to use wchar_t instead of unsigned short.
>
>   
Thats cool, I will be interested how that works out.
> After setting that, I'm still not having any luck. If I use the ASCII
> variant of the SQLConnect(), all is well:
>
> rv = SQLConnect(hdlConn, (SQLCHAR*) "MyDSN", SQL_NTS, (SQLCHAR*)
> "dbuser", SQL_NTS, (SQLCHAR*) "verysecret", SQL_NTS);
>
> And I can connect. If I use the wide version, it doesn't:
>
> rv = SQLConnectW(hdlConn, (SQLWCHAR*) L"MyDSN", SQL_NTS, (SQLWCHAR*)
> L"dbuser", SQL_NTS, (SQLWCHAR*) L"verysecret", SQL_NTS);
>   
Ok, that should be fine assuming they are 16 bit, and the right 
endianness, are you on a x86 type platform? (shouldn't matter, but just 
trying to catch any posible problems)
> I have also created unsigned short arrays and manually populated them,
> with the same results. I get this error:
>
> [unixODBC][ (48) (ret=-1)
>   
May be worth checking the error message that comes back, if its can't 
find driver, then unixODBC has failed to decode the string, if something 
else, it may have got to the driver and failed there. Another way to 
check (other than putting debug in the unixODBC code which is a good way 
of doing things) is to run your test under strace, look to see if it 
loaded the driver lib, if it did, then unixODBC at least understood the 
connection string.

Also worth using driver manager logging. the log contains the file and 
line number where the message was logged, that (along with the driver 
manager source) can be a big help to see whats wrong.

I should have asked before, what version of unixODBC are you using. 
Current ones should be fine with wjat you are doing, but there were 
variationsin the older versions.
> I also discovered SQL_NTSL, but I'm not sure what its purpose is - I
> couldn't find any documentation. I'm not sure what I'm doing wrong at
> this point.
>   
Me neither, it may have come from the MS docs years ago, I will check.
> I do have two other questions though:
>
> 1. Do I have to use SQLConnectW() in order to submit any UCS-2 data
> (e.g. using SQLExecDirectW()) to the database using ODBC? Or can I use
> SQLConnect() and then SQLExecDirectW()?
>
>   
Yep, thats fine, however in older version it would decide the driver was 
ascii and convert the string to ascii, maybe try using 2 2.15pre (on ftp 
site) at least then we are both on the same sheet, and I can try 
reproducing what you are doing.
> 2. If I use SQLConnectW(), then does the odbc.ini file also have to be
> encoded in UTF-16/UCS-2?
>
>   
No, the ini is always ascii. its potentially a problem if you wanted 
unicode in there, but the only way I can see of making that work in a 
sensible way is switching the ini to use XML.

-- 
Nick