[freetds] dbcoltype() , char and nchar
lacak at zoznam.sk
Thu Sep 16 08:04:27 EDT 2010
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
(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
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
May be SIZE / 4 ? (where 4 is max number of bytes, which are required to
encode 1 character in client encoding)
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)
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)
> 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
More information about the FreeTDS