| Subject | Re: [Firebird-Java] Re: Character Set question (practical & philosophical) |
|---|---|
| Author | Adriano dos Santos Fernandes |
| Post date | 2005-01-22T14:56:16Z |
Roman Rokytskyy wrote:
1) Connecting with NONE, sqlsubtype of XSQLVAR is 127 (connection charset).
2) Connecting with UNICODE_FSS isn't safe because sqllen of XSQLVAR is 1 (instead of 3) if the WIN1252 column is CHAR(1) then you can't retrieve the string 'รก'.
In new INTL:
1) If you connect with NONE, sqlsubtype is 53 (WIN1252) and you know the original charset of the column.
2) sqllen is calculated and in this example it will be 3.
This is explained with examples in thread "Length of descriptors" in fb-devel.
I think with new INTL John can connect with UNICODE_FSS, UTF8 or NONE and the result will be the same: only one conversion, in the server or in the client.
Adriano
>I see two problems in old INTL, for example if you have one column using WIN1252:
> Since there is no way to convert NONE into something else. If you have
> database with WIN1252, but your client is NONE, then you have read-only
> access. At least so it was till now. Did you change this behavior in new
> INTL stuff?
>
1) Connecting with NONE, sqlsubtype of XSQLVAR is 127 (connection charset).
2) Connecting with UNICODE_FSS isn't safe because sqllen of XSQLVAR is 1 (instead of 3) if the WIN1252 column is CHAR(1) then you can't retrieve the string 'รก'.
In new INTL:
1) If you connect with NONE, sqlsubtype is 53 (WIN1252) and you know the original charset of the column.
2) sqllen is calculated and in this example it will be 3.
This is explained with examples in thread "Length of descriptors" in fb-devel.
I think with new INTL John can connect with UNICODE_FSS, UTF8 or NONE and the result will be the same: only one conversion, in the server or in the client.
Adriano