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: LacaK <lacak AT zoznam.sk>
  • To: FreeTDS Development Group <freetds AT lists.ibiblio.org>
  • Subject: Re: [freetds] dbcoltype() , char and nchar
  • Date: Thu, 16 Sep 2010 14:04:27 +0200

Hi James,
yes it sounds logically what you wrote.

Only for explanation:
In FreePascal there are different Database Field Types
TStringField and TWideStringField, so my attempt was map
char, varchar to TStringField
nchar, nvarchar to TWideStringField (see http://docwiki.embarcadero.com/VCL/en/DB.TWideStringField )
(text to TMemoField, ntext to TWideMemoField)

ATM I have this dilema:
1. on server is field1 defined as nchar(10) and field2 defined as char(10)
2. client encoding is set to UTF-8
3. column field1 is in dbcolinfo() described as SYBCHAR with SIZE=40 and also field2 is described as SYBCHAR with SIZE=40

Problem1:
If I set TStringField.Size=40 that means, that 40 characters can be stored, but this is not true, because on server side are columns defined with maxlength 10

How to obtain servers column size ? (10 for both columns ... to properly set TField.Size?)
May be SIZE / 4 ? (where 4 is max number of bytes, which are required to encode 1 character in client encoding)

Problem2:
If I set TStringField.Size=10 (40/4) then 11 bytes are reserved in record buffer for fields data, so I can not store there potentialy required 40 bytes in UTF-8 encoding
(TWideStringField reserves 22 bytes in record buffer, which is much better)

Conclusion:
If I will be able to detect nchar,nvarchar then I will create TWideStringField with Size=10 and convert data from UTF-8 to UTF-16 ,
for char and varchar I can create TStringField with Size=10 and convert data from UTF-8 to Ansi (local system codepage)

Thanks
-Laco.

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






Archive powered by MHonArc 2.6.24.

Top of Page