[freetds] dbcoltype() , char and nchar
mpeppler at peppler.org
Tue Sep 14 00:45:30 EDT 2010
Actually, Sybase does use Unicode (for unichar/unitext columns).
But you're correct in saying that Sybase (ASE, that is) can't run with Unicode as it's charset.
On Sep 14, 2010, at 3:42 AM, James K. Lowden wrote:
> LacaK wrote:
>> there is in db-lib function dbcoltype, which returns result column
>> datatype. on CHAR column it returns SQLCHAR (SYBCHAR)
>> on VARCHAR it returns also SQLCHAR
>> on NCHAR, NVARCHAR it returns also SQLCHAR ... but here I need
>> distinguish between CHAR and NCHAR (NATIONAL CHAR - UNICODE CHAR)
>> Is there any way how to get this more detailed column info (in example
>> below is it wtype/wsize, column "nchar_field" is defined as nchar(10))?
>> If not, is there way how to extend (dbcolinfo?) and/or add some function
>> or parameter which will solve this problem ?
> At the moment, you're a little bit stuck. We could talk about how to
> extend db-lib, but neither vendor defines anything like SYBNVARCHAR.
> It's not clear to me that it should, or that you should care! Granted,
> dbcoltype() returns "the column type" as defined by the server and granted
> CHAR and NCHAR are two different types. OTOH, they're not different,
> really: they're character data. NCHAR uses USC-2 encoding, but so what?
> CHAR doesn't promise an encoding. If you want to know the encoding the
> server's using -- and it's not clear you *should* want to know that,
> either -- there would need to be a brand new function for that,
> dbencoding() or somesuch.
> Bear in mind Sybase doesn't use UCS-2. If you want Unicode on Sybase, you
> use UTF-8, and you're told it's SYBCHAR (because it's a CHAR column, just
> as Codd intended). So if you were to act on something like SYBNVARCHAR,
> you'd have a Microsoftism in your code and *still* not have it right for
> Sybase. I think that makes three strikes against.
> Why should the application care about the server's encoding? The
> application should attempt to bind/convert the column to a char buffer.
> Implicitly FreeTDS will convert that to the client's encoding. If it
> can't be represented that way, that's a general problem, not specific to
> NVARCHAR columns.
>  Physical Data Independence is one of Codd's Rules for defining a
> relational database. The server doesn't have to use UCS-2 or even IEEE
> 754, nor even tell you in what format the data are stored. And you
> needn't *care* how integers, floats, dates, or characters are *stored*,
> only their ranges and how they can be represented in the host programming
> language (C in this case). Two clients can use different formats for all
> those things and still share the same dataabase. 'Twas not always thus.
> FreeTDS mailing list
> FreeTDS at lists.ibiblio.org
Sybase on Linux FAQ: http://www.peppler.org/FAQ/linux.html
"A successful [software] tool is one that was used to do something undreamed of by its author." -- S. C. Johnson
More information about the FreeTDS