As I don't use EDB now, I wonder if it still uses the Language features of
windows like DBSIAM. As I have stepped into a unsolvabel catastrophic
problem with the german language drivers under Vista I wonder if EDB is also
affected by this problem.

So the description of this catastrophic problem is related to DBISAM, but it
may affect EDB too:
Under Vista langugae drivers are broken in a very strange way as the
following situtation now can occur:

Under XP I can't enter two records with an PK of 'Muller' and 'Müller'. This
is interpreted as the same wich is ok so, but under Vista this is not
anymore interpreted as the same and so we are just fine to save 2 records
with this PK. Now the probeml is that if anyone under XP is accessing this
records, strange things happens, such as corrupt indexpages errors on
deletions or selecting the wrong record on search and such things.

Another thing in Vista has change fro the german language is that 'Müller'
and 'Mueller' is now interpreted as the same while in XP this was two
different words. The behaviour of Vista is completly wrong, as this two word
ARE two words.

As MS isn't going to fix that bug (see my other thread) I'm now completly
lost and I have no idea how I can fix that problem?! If EDB is still using
the windows locales it will be affected by this Vista change too. Accessing
this tables form Vista and XP systems togehter will be a disaster.

Please see my other post in public.dbisam.general too.

As far I have tested now, this is not only a german language table problem
but a problem on every non ANSI laguage tables, where someone enters german
Umlauts. Whatever Language my table have (as a sample English(USA)) if wny
one entere "Müller" in one record and "Muller" in another record, this will
produce a keyviolation under XP but under Vistra this works well. As a
result there will be big problems under XP if someone has entered such
records under Vista. And the other way around the same if anyone enters
"Müller" and "Mueller" under XP, which is valid under XP but not valid under
Vista and anyone on vista is accesing this data.

This looks as a extremly big problem for Elevatesoft, an the only solution
will be to use not anymore comparesrtring, but some own compareroutines,
which don't use the windows locales, as the moste other DB-systems do.

I don't have any idea, what I schould do now. For me it looks as I must
change the DB-System because of that Vista crap!!! Something I absolutly
don't want to do.

My complete xmas days were ruined by that Vista crap.

Tim what are your plans to do about this problem?

Regards
Rolf


"Rolf Frei" <rolf@eicom.ch> schrieb im Newsbeitrag
news:25F1B341-7BB9-43D5-B4B2-A0C8602CA96A@news.elevatesoft.com...
> As I don't use EDB now, I wonder if it still uses the Language features of
> windows like DBSIAM. As I have stepped into a unsolvabel catastrophic
> problem with the german language drivers under Vista I wonder if EDB is
> also affected by this problem.
>
> So the description of this catastrophic problem is related to DBISAM, but
> it may affect EDB too:
> Under Vista langugae drivers are broken in a very strange way as the
> following situtation now can occur:
>
> Under XP I can't enter two records with an PK of 'Muller' and 'Müller'.
> This is interpreted as the same wich is ok so, but under Vista this is not
> anymore interpreted as the same and so we are just fine to save 2 records
> with this PK. Now the probeml is that if anyone under XP is accessing this
> records, strange things happens, such as corrupt indexpages errors on
> deletions or selecting the wrong record on search and such things.
>
> Another thing in Vista has change fro the german language is that 'Müller'
> and 'Mueller' is now interpreted as the same while in XP this was two
> different words. The behaviour of Vista is completly wrong, as this two
> word ARE two words.
>
> As MS isn't going to fix that bug (see my other thread) I'm now completly
> lost and I have no idea how I can fix that problem?! If EDB is still using
> the windows locales it will be affected by this Vista change too.
> Accessing this tables form Vista and XP systems togehter will be a
> disaster.
>
> Please see my other post in public.dbisam.general too.
>

Rolf,

<< This looks as a extremly big problem for Elevatesoft, an the only
solution will be to use not anymore comparesrtring, but some own
compareroutines, which don't use the windows locales, as the moste other
DB-systems do. >>

No, it's not our problem, and no, we won't be switching the way that we do
collation/sorting.  The solution to this issue is simple if you're using
Vista or above - either turn on Windows XP SP2 compatibility or use the
ElevateDB Server.  That will solve the problem.

<< I don't have any idea, what I schould do now. For me it looks as I must
change the DB-System because of that Vista crap!!! Something I absolutly
don't want to do. >>

Well, you'll probably experience the same problem with other Windows
database systems, especially any from MS - they all use the Windows
collation facilities for sorting/searching.

--
Tim Young
Elevate Software
www.elevatesoft.com

I don't know if you have relay checked the problem. It's not the sorting wht
is the problem. The problem is that the Uniquey keys are not anymore handled
the same. As such, if the tables are managed by a XP and a Vista client we
get stong prolbems with corrupt indexes and wrong finding of wrong records.
Aa of the XP point of view there are records in the tables which violates
the unique keys rule. On XP we cant add two records with "Müller" and
"Muller" as this is for Xp the same key. Under Vista they are two diffrent
words and can be enetered there mith no Duplicatied Key errror. Now ic the
XP user acceses this tabelrecords he will get wrong results, specialle for
any relational Table which than selects the wrong records. Trying to deletet
such records will produce an index corrupt error.

If you say that is not your problem ist very naive. I don't konw any other
DB System who uses CompareString für unique keys calcuations. Sorting is an
other thing and not the problem here. It's the fact that we get corrupt DB's
now. Sorry but that is a show stopper problem for me, and for every german
user out there, whcih uses a string field as a Primary Kex or Unique Key.

Regards
Rolf


"Tim Young [Elevate Software]" <timyoung@elevatesoft.com> schrieb im
Newsbeitrag
news:D457224C-2E77-4FBC-9463-A4E1780071AD@news.elevatesoft.com...
> Rolf,
>
> << This looks as a extremly big problem for Elevatesoft, an the only
> solution will be to use not anymore comparesrtring, but some own
> compareroutines, which don't use the windows locales, as the moste other
> DB-systems do. >>
>
> No, it's not our problem, and no, we won't be switching the way that we do
> collation/sorting.  The solution to this issue is simple if you're using
> Vista or above - either turn on Windows XP SP2 compatibility or use the
> ElevateDB Server.  That will solve the problem.
>
> << I don't have any idea, what I schould do now. For me it looks as I must
> change the DB-System because of that Vista crap!!! Something I absolutly
> don't want to do. >>
>
> Well, you'll probably experience the same problem with other Windows
> database systems, especially any from MS - they all use the Windows
> collation facilities for sorting/searching.
>
> --
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Rolf,

<< I don't know if you have relay checked the problem. It's not the sorting
wht is the problem. The problem is that the Uniquey keys are not anymore
handled the same. >>

Sorting and unique keys are one and the same.  Both are determined by the
result of a CompareString call or calls.  Indexes are used to support
primary and unique keys, and indexes use CompareString on string columns to
determine the sorted order of the index.

<< As such, if the tables are managed by a XP and a Vista client we get
stong prolbems with corrupt indexes and wrong finding of wrong records. Aa
of the XP point of view there are records in the tables which violates the
unique keys rule. On XP we cant add two records with "Müller" and "Muller"
as this is for Xp the same key. Under Vista they are two diffrent words and
can be enetered there mith no Duplicatied Key errror. Now ic the XP user
acceses this tabelrecords he will get wrong results, specialle for any
relational Table which than selects the wrong records. Trying to deletet
such records will produce an index corrupt error. >>

Yes, you are correct.

<< If you say that is not your problem ist very naive. I don't konw any
other DB System who uses CompareString für unique keys calcuations. Sorting
is an other thing and not the problem here. It's the fact that we get
corrupt DB's  now. Sorry but that is a show stopper problem for me, and for
every german user out there, whcih uses a string field as a Primary Kex or
Unique Key. >>

I've spent the last 10 years developing database engines, so I think that
I've got a little better insight into this issue than you.  CompareString is
the only way to accurately compare both Ansi and Unicode strings in a
collation-specific manner.  How would you determine whether two Ansi or
Unicode strings were the same in any available language or locale ?  I
suspect that you won't have an answer for that.

I don't remember you complaining to us prior to this bug ?  I guess it was
okay that we did it that provided that MS didn't screw up and introduce a
bug.  I'm not about to change our entire database engine in order to
replicate the entire locale/collation support in Windows because of one bug
in one specific collation in one specific version of Windows.   It's not
going to happen, so you can stop asking and save yourself some time.

--
Tim Young
Elevate Software
www.elevatesoft.com