Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » ElevateDB Technical Support » Support Forums » ElevateDB General » View Thread |
Messages 1 to 5 of 5 total |
Vista: ElevateDB/DBISAM german table language disaster?! |
Tue, Dec 25 2007 11:49 AM | Permanent Link |
Rolf Frei eicom GmbH | 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. |
Thu, Dec 27 2007 9:20 AM | Permanent Link |
Rolf Frei eicom GmbH | 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. > |
Thu, Dec 27 2007 3:47 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Fri, Dec 28 2007 9:08 AM | Permanent Link |
Rolf Frei eicom GmbH | 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 > |
Fri, Dec 28 2007 3:15 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
This web page was last updated on Wednesday, April 24, 2024 at 11:07 AM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |