[freetds] dbcoltype() , char and nchar
LacaK
lacak at zoznam.sk
Thu Sep 16 08:04:27 EDT 2010
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
>
>
More information about the FreeTDS
mailing list