LocaleName (Rephrase)

Joakim Schramm joakim at astrocalc.com
Wed Dec 13 12:35:20 CST 2006


Hi Ivan,

So ok most things clear to me :-) so Locale IS I/O encoding right?

Just one thing refering to what Ruslan said that Locale effect indexing,
does this also then include order of sorting, like in Czech CH is counted as
1 character and comes before H, not D, this LocaleName effect then?

You say I should set I/O encode each time I open - if I set it - but I
checked, if I change LocaleName in code, same Locale is used next time db
opens? So if I set this I only need to do it once, preferable at install or
first time open only, I think.

/Joakim 

> -----Original Message-----
> From: valentina-bounces at lists.macserve.net 
> [mailto:valentina-bounces at lists.macserve.net] On Behalf Of Ivan Smahin
> Sent: 13 December 2006 11:20
> To: Valentina Developers
> Subject: Re: LocaleName (Rephrase)
> 
> Hello Joakim,
> 
> Tuesday, December 12, 2006, 8:37:25 PM, you wrote:
> 
> > Ok,
> 
> > I have read the kernel document and it doesn't really answer my 
> > questions, actually it adds one :-) or I am uncertain about 
> one thing. 
> > It is talking about 2 different kinds of encoding 
> available, Storage 
> > Encoding and I/O encoding. It then doesn't meantion the 
> latter anymore 
> > except telling it's what get into and out of fields. So althought 
> > stays unclear on this point I assume locale is the I/O encoding?
> 
> I would say:
> When   you  set  some  I/O  Encoding  you  say:  "I promise to give to
> valentina's  database  data  encoded in particular codepage 
> and I want to  get the data in that way back." It is 
> per-session settings. I mean you should set it each time you 
> operate with database.
> This  setting  does  not  touch  the  storage. It decodes 
> your data to storage encoding just before store it and encode 
> storage-data each time you retrieve it.
> So this settings does not affect other sessions.
> 
> Storage  encoding  is responsible for how the database is 
> storing the data.  This setting is storable - so you don't 
> need to set it each time.
> It decodes any data to storage encoding just before store it.
> 
> 
> > Then let me rephrase my previous questions and put it in as 
> example of 
> > my database. In my database I store data about almost every 
> City/Town 
> > available on the earth (except for very small places). The 
> bigger part 
> > is numeric data but there is some VarChar fields typically for Town 
> > names and countries or other "labels", then there is 1 
> DateTime field. 
> > The database it set to Storage Encoding UTF-16.
> 
> > First, Country and Town names exist in various versions regarding 
> > spelling as they can spell differently in different 
> languages. What I 
> > am concerned about here is that when the database is used on a 
> > computer these names will show as they should be in 
> original language. 
> > All I/O controls in my app is full Unicode aware. Will the 
> locale set 
> > in Valentina affect how this is displayed? I ask because in Vstudio 
> > this isn't the case always, but maybe Vstudio controls 
> isn't Unicode?
> 
> It  should be so. If you operates with UTF16 - there is no 
> need to set any I/O Encoding.
> 
> > When populate data into database I have changed my 
> computers setting 
> > to resamble that country, I have then read the data in by code from 
> > unicode files with correct spelling. So is this "preserved" inside 
> > Valentina dispite change of locale? Or locale has nothing 
> to do with 
> > this how characters are displayed when UTF-16?
> 
> Yes.  It  would  be nothing to do if data comes as UTF16 and 
> stored in this way also.
> 
> > Second thing is my DateTime Field, will locale change how 
> it behave or 
> > just how it "look"? Like in VB as an example, dates can be formated 
> > differently but inside VB always use the same format no 
> matter which 
> > locale set. What I do here is typically compare one DateTime value 
> > from code with what is stored in db to find a range of 
> datetime this falls into.
> 
> Currently  date  fields  is not affected by locale. There is 
> different properties set such as dateFormat, separator and so on.
> 
> > As I do now I only set locale to VarChar field and leave rest as 
> > original which is en_US (or if it en_UK), but setting locale to 1 
> > field with 250 000 records takes 4sec! But maybe Valentina have to 
> > traverse all records, then it's logical. However what I 
> think is maybe 
> > I don't have to set locale at all? Well I am a bit confused 
> about this 
> > :-) I don't know exactly how and what it affect in my db, 
> like if it metetrs if I have UTF-16 whole database.
> 
> If you use the UTF-16 only you should do nothing in this area.
> 
> 
> 
> --
> Best regards,
>  Ivan                            mailto:ivan_smahin at valentina-db.com
> 
> _______________________________________________
> Valentina mailing list
> Valentina at lists.macserve.net
> http://lists.macserve.net/mailman/listinfo/valentina
> 



More information about the Valentina mailing list