Skip to Content.
Sympa Menu

freetds - Re: [freetds] a better libtds

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: "James K. Lowden" <jklowden AT freetds.org>
  • To: freetds AT lists.ibiblio.org
  • Subject: Re: [freetds] a better libtds
  • Date: Mon, 22 Aug 2011 15:05:57 -0400

On Sun, 21 Aug 2011 11:53:51 +0200
Frediano Ziglio <freddy77 AT gmail.com> wrote:

> And also dblib does not support wide characters.

True, but it could. I think db-lib works well enough now that we could
call it 1.0; within the subset we intended to implement, it does
everything the vendors' implementations do. The specifications
handed us don't address Unicode because Sybase & Microsoft have both
deprecated db-lib. Therefore we're free to extend in any way that
doesn't break compatibility.

DB-Library defines some parameters and returned strings as type
CHAR. So, dbcolname() must return CHAR*, and "everyone knows" that's a
single-byte encoding. Other functions, such as dbuse() take a char*.
Still others e.g. dbbind() use BYTE*.

The answer? All functions returning character data (either by
returning a pointer or by filling a client-provided buffer) should use
the encoding specified by DBSETLCHARSET() or "client charset" in
freetds.conf. Regardless of char*, CHAR*, or BYTE*, if DBSETLCHARSET()
indicates UCS2, the client gets UCS2. That includes the strings passed
to the message & error handlers.

I think that covers it. Wide characters are currently unsupported in
any existing db-lib, including ours. Redefining character pointers
won't affect any existing applications, and new ones get one consistent
change.

I don't see any need to duplicate the function names with W or A, the
way ODBC does.

--jkl




Archive powered by MHonArc 2.6.24.

Top of Page