> Actually, reading one of the links you posted
> (http://blogs.msdn.com/michkap/archive/2005/05/04/414520.aspx -
> everybody please read it before continuing in discussion), I got (what
> I think is a great) idea: Let's include version information about
> collation algorithm we are using. So, extending my previous
> suggestion, the SQLite collation title would look like
> 'en_AU_Win_2_1', where the individual parts mean:
> 'en_AU' - obviously a sort order
> 'Win' - that we are basing the ordering on default Windows methods
> (otherwise could be e.g. 'ICU')
> '2_1' - version string as retrieved from GetNLSVersion() function and
> NLSVERSIONINFO struct (see the link above for details).
I don't see how that is different than the previous difficulty of
having incompatible databases between systems. The only new thing is
we can check it, but the database will have inconsistent behaviour
anyway.
As I wrote, my main intention was to handle incompatibilities among
applications reading a database on a given system - and this would
handle the issue perfectly.
> This way we are absolutely sure that we don't corrupt SQLite database.
> While I'm working on a single system, the version string wouldn't
> change. Then, e.g. if I open SQLite database with 'en_AU_Win_2_1'
> collation on a system NLSVERSIONINFO returns version 2.3, I know I
> have to reindex, change collation title to 'en_AU_Win_2_3' and then
> can safely use the database.
For small databases, the task of re-indexing is not big, but you are
forgetting you can have a database in a shared network folder, used by
PC's in different parts of the world and even different OSs (with
samba/cifs). That's why I like Trevor's idea so much.
You are right in this, my proposal handles some problems, but can't
handle this situation. That said, it at least allows sharing databases
under compatible platforms - which is still an improvement over the
current situation where every application has its own collation and
there's absolutely no compatibility.
Trevor proposed method doesn't need that, because the collation data
goes with the database (which is the big advantage to me). And if you
want to use another collation, you only need to import the collation
data needed for that locale.
Well, Trevor's proposal sounds good indeed, but realistically, I don't
see any big chances it to be implemented - collations aren't that
simple and maintaining all the related issues without relying on some
external code is probably too much to expect.
Jiri
-----------------------------------------------------------------------------
To unsubscribe, send email to [EMAIL PROTECTED]
-----------------------------------------------------------------------------
