[freetds] On unicode strings support
Michael.Kochetkov at synartra.com
Thu Oct 7 09:49:58 EDT 2004
> > Hello,
> > SQLDescribeCol returns SQL_VARCHAR - 12 - type for MS SQL Server
> > nvarchar(...) field at present. The FreeTDS documentation
> > states that "At
> > some future time, FreeTDS aims to support Unicode and other
> > character sets. It does not do so at the current time."
> > Do you plan to path the unicode strings as is through the
> > FreeTDS layer in
> > the nearest future? If no then is it considered to be hard if
> > I decide to
> > implement it myself?
> > Thank you in advance,
> It's difficult to describe how current FreeTDS support unicode. If you
> set charset to UTF-8 you can say that FreeTDS support unicode
> but if you
> mean ODBC 3.5 extension (like SQLDescribeColW or SQL_WVARCHAR) FreeTDS
> do not support unicode (FreeTDS ODBC it's 3.0, not 3.5).
> How hard it's to add support for ODBC 3.5 and wide character? libTDS
> (the core of FreeTDS) currently convert any char it receive to client
> charset ASAP. ODBC 3.5 require that you can translate to multi-byte
> encoding and to "unicode" (for portability reason it's better
> to call it
> wide character in this context). So IMHO libTDS should be
> able to store
> data in original format just to be prepared to convert data into wide
> character or client charset. However this raise also a big problem.
> What's to return from SQL_DESC_OCTET_LENGTH or SQL_DESC_LENGTH? For
> example if a column it's varchar(10) and we fetch
> what information to return ? Keep in mind that if varchar contains for
> example 6 bytes (that's different from 6 characters) this can be
> converted to 3 wide characters or even 6 wide characters depending on
Well, thank you for clarifications. I would be satisfied with SQL_WVARCHAR
support a la blobs - no convertions or special treatment, just -8 and -9
data types codes and raw data. But OK, we have already resigned ourselves to
loosing the unicode support.
More information about the FreeTDS