Re: dbcoltype() , char and nchar

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[1] -- 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.  

--jkl

[1] 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.