Re: dbcoltype() , char and nchar

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