Eigenartiger Effekt mit int-Primary Keys ?

[nahpets]

Zitat von gmc616:

Interessanter Weise tritt dieser Fehler NUR im MSSQL-2008R2 und MSSQL-2012 auf und immer bei den gleichen Schlüsseln 5366038 bzw. 5365874.
Ich habe ca. 20 Installationen am laufen, die diesen Fehler produziert haben. Und es betrifft immer einen dieser beiden Schlüssel.

Dies erscheint mir sehr befremdlich.

Gibt es Installationen mit diesen Datenbanken, bei denen

1. der Fehler nicht aufgetreten ist, also Sätze mit den IDs -5366038 und -5365874 existieren
2. und keine IDs 5366038 und 5365874 existieren
3. und die weitere ID-Vergabe korrekt verlief?

Wieviele Nutzer können gleichzeitig mit einer Datenbank arbeiten?
Single-User-Betrieb oder Multi-User-Betrieb?

Um besser Hilfestellung geben zu können, wäre es eventuell hilfreich, wenn Du uns eine Liste der genutzten Datenbanken geben könntest.
Für eine Problemlösung für unterschiedliche Datenbanken muss letztlich SQL-technisch der kleinste gemeinsame Nenner genutzt werden, um Dein Programm kompatibel zu allen genutzten Datenbanken zu halten.

***

Gehen wir nochmal von Deinem Code aus:

Aktuell sei ID = 5366037

Code:

// PseudoCode
TAdoCon.BeginTrans;

UPDATE nidents SET id=id+1 WHERE tbname=:TableName AND idname=:PkName;
SELECT id from nidents where tbname=:TableName AND idname=:PkName;

TAdoCon.CommitTrans;

Dann liefert das Select für ID den Wert 5366038.

Der Satz wird nun gelöscht:

Code:

UPDATE tabelle SET id=ABS(id)*-1 WHERE id=5366038;

ID ist nun -5366038.

Würde vom MSSQL-Server ausgeführt

Code:

UPDATE tabelle SET id=ABS(id)*-1 WHERE id =NULL;

so wäre ID weiterhin 5366038, dem Satz fehlt in diesem Fall nur die Löschmarkierung.

Eine ID-Dublette kann hier daher nicht entstanden sein.

Eine ID-Dublette kann nur dann entstehen, wenn obiger "PseudoCode" zweimal das gleiche Ergebnis liefert.

Da nicht bekannt ist, wie der tatsächliche Programmablauf erfolgt, könnte hier aber ein Problem vorliegen.

Wenn mehrere Benutzer (und / oder mehrere Threads) gleichzeitig diesen Code ausführen, kann es zu Dubletten kommen. Beim Lesen der ID per Select ist der mit Update gesetzte Wert noch nicht in der Datenbank festgeschrieben, theoretisch könnte ein zweiter User annähernd zeitgleich daher zum gleichen Ergebnis kommen.
Meiner Meinung nach wäre es sinnvoller, zuerst die ID in einer eigenen Transaktion in der Tabelle nidents zu erhöhen und erst nach dem Commit per SQL auszulesen, aber 100% sicher erscheint mir diese Lösung auch nicht.

Code:

// PseudoCode
TAdoCon.BeginTrans;
UPDATE nidents SET id=id+1 WHERE tbname=:TableName AND idname=:PkName;
TAdoCon.CommitTrans;
SELECT id from nidents where tbname=:TableName AND idname=:PkName;

Irritierend finde ich allerdings schon, dass der Fehler nur bei zwei Datenbanktypen mit zwei bestimmten IDs aufgetreten ist.