[unixODBC-dev] iconv/ICU

Nick Gorham nick.gorham at easysoft.com
Tue Nov 6 10:36:40 GMT 2007

Peter Harvey wrote:

> From cvs...
>A. SQLPrepareW.c Line 149 appears to dumb down the SQL text for an error 
>message. This could result in some character loss. In fact the trace file 
>content seems to be limited to 8bit characters at the moment. 
Yes, but only for the message in the log, any string passed back to the 
app will be as the driver sent it.

>B. At the moment anything going to/from the ini files must be 8bit characters. 
>A DSN value string could loose characters and so can any other value string.
Well, yes, but where are you going to find a unicode odbc.ini text file, 
unless its UTF8. which should be handled.

>C. SQLDriverConnectW.c Line 142 appears to dumb down the entire connect 
>string - which will probably be fine for the keywords but not always for the 
>values. This applies to the SQLBrowseConnectW as well.
Yes, but only to extract the keywords the DM needs, the original is 
passed to the driver unchanged. Ok, you may have a driver in 
odbcinst,ini with a unicode name, but it seems unlikely to me.

>1. My understanding is that ICU supports many more encodings than does iconv.
Yes, that may be true, but is the lack causing anyone to have a problem?

>2. I bet some string handling code in unixODBC may be simplified or removed as 
>ICU does support some string handling beyond conversion.
I can't see how adding an additional library with all the attendent 
build and porting issues that it will entail is going to outweigh some 
string handling.

>3. ICU supports translation tables which could be handy for diagnostic 
>messages and trace messages.
Thats more a i18n issue though, which is an entirely different matter. 
If it was needed to add message catalogs, then fine, lets look at that, 
but other than one Polish pot, for the GTK odbcconfig, I have never been 
asked for such a thing.

>Anyway... just more thinking out-loud. Its very late here so I am off to bed. 
>I may look for more (better) examples tomorrow.
Ok, I do fall on the side of Steves point about this, it seems IMHO to 
be a solution in search of a problem.

Nick Gorham
Easysoft Limited
http://www.easysoft.com, http://www.unixODBC.org

More information about the unixODBC-dev mailing list