V4RB, Jon, project

[Ruslan Zasukhin]

On 9/15/04 2:46 PM, "jda" <jda at his.com> wrote:

>>> Ruslan, please clarify this.
>> 
>> I have not catch your point guys.
>> 
>> * internally engine always work in UTF16
>> 
>> * so even if RB give me UTF8 string, I convert it to UTF16.
>>     when I write to disk I convert it from UTF16 to encoding
>>     which you have specify in the property StorageEncoding.
>> 
>> * fixed size Vstring with UTF8 cause the most big problems.
>>     VarChar field less problems.
>>     Vtext no problems because no top limit.
>> 
> 
> Good, that's what I had thought -- we do specify the way the data are
> stored, and Valentina converts whatever it is to UTF-16 for internal
> manipulation (searches, sorts, etc.).
> 
> But I'm still confused. You said we can change the encoding on a
> field-by-field basis. But is that the *storageEncoding*?

YES. You have
    
    Vdatabase.storageEncoding
    VTable.storageEncoding
    VField.storageEncoding


> If it is, that solves all problems, because we can use UTF-16 for VString and
> UTF-8 for VText if we want.

yes

> If it is not the storageEncoding (which
> I'm guessing is the case, because there is a global property for
> that) then it doesn't help.

no

> So the question again, better phrased, is might it be possible to
> assign a different storageEncoding for each field? If not now, is
> that feasible to implement?

YES!!!

YES!!!!!

YES !!!!!!

It is already implemented.

    Vdatabase.storageEncoding
    VTable.storageEncoding
    VField.storageEncoding

And this parameter can be inherited from top level.


-- 
Best regards,
Ruslan Zasukhin      [ I feel the need...the need for speed ]
-------------------------------------------------------------
e-mail: ruslan at paradigmasoft.com
web: http://www.paradigmasoft.com

To subscribe to the Valentina mail list go to:
http://lists.macserve.net/mailman/listinfo/valentina
-------------------------------------------------------------