Skip to Content.
Sympa Menu

freetds - Re: [freetds] dbcoltype() , char and nchar

freetds AT lists.ibiblio.org

Subject: FreeTDS Development Group

List archive

Chronological Thread  
  • From: Michael Peppler <mpeppler AT peppler.org>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] dbcoltype() , char and nchar
  • Date: Tue, 14 Sep 2010 06:45:30 +0200

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
> FreeTDS AT lists.ibiblio.org
> 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










Archive powered by MHonArc 2.6.24.

Top of Page