Re: dbcoltype() , char and nchar

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.

Michael


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[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.  
> 
> _______________________________________________
> FreeTDS mailing list
> [email protected]
> http://lists.ibiblio.org/mailman/listinfo/freetds
> 

--
Michael Peppler
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