Eigenartiger Effekt mit int-Primary Keys ?

[jobo]

Zitat von baumina:

[OT]
Ganz ehrlich: Ich ärgere mich über dieses Verhalten und finde es nur zum .
[/OT]

@gmc616
Hast Du auch den richtigen Code statt den Pseudocode?
Der Isolationlevel kann ein Problem sein, wenn auch nicht commitete Werte gelesen werden.
Was passiert, wenn Du eine AdoQuery auf ein neues Formular setzt und genau diese Statements ausführst?
Wie alt/neu sind Deine ADO Treiber und die der Kunden?
Was geschieht mit Werten, die über diese problematischen Werte hinausgehen?

[DeddyH]

Dem schließe ich mich an (Letzteres ist rein platonisch gemeint, nicht dass da jemand falsche Schlüsse zieht).

[jobo]

Zitat von DeddyH:

Dem schließe ich mich an (Letzteres ist rein platonisch gemeint, nicht dass da jemand falsche Schlüsse zieht).

Ich glaube, die "Aktualisierungen" eigenen sich hervorragend, um einen ganz falschen-wenn auch platonischen- Eindruck zu erzeugen.
Oder wollen wir uns doch mal treffen DeddyH?

[Daniel]

Ups. Mein Fehler - der Beitrag von DeddyH hätte mit abgetrennt werden müssen.
Sorry dafür.

[jobo]

Kein Problem meinetwegen, ist schließlich Karneval. Ich weiß natürlich nicht wie DeddyH das sieht.

@Abtrennung: Hab ich nun auch endlich geschnallt, dass das Thema "Umgang" verlagert wurde.
http://www.delphipraxis.net/188167-e...rt-gebern.html

[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.

[p80286]

Zitat von nahpets:

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

Das hake ich unter Zufall ab. Weit wichtiger ist, wie wird eine ID "negativiert", da gibt es ja mehrere Möglichkeiten, und auf welcher Basis wird eine neue ID berechnet.

(vor vielen Jahren war es Zeichen besonders cleveren Programmierens 16Bit-Words zu nutzen, die gehen ja bis 65.000 und soooviele Datensätze haben wir nieeee. Abgesehen von der etwas kurzsichtigen Sichtweise was die Datenmenge angeht, was passiert wenn auf diesen 16Bit-Wert mal als Word und mal als Integer zugegriffen wird??)


Gruß
K-H

[Dejan Vu]

Bei 20 Installationen ist das kein Zufall mehr. Es scheint doch so zu sein, das es bei allen Installationen auffällt. Ich tippe ja auch auf die Software selbst, aber das muss schon ein merkwürdiger Zufall sein.

Code:

Update Tabelle set Id=5366038 where ....

Gemein ist das in jedem Fall.

[p80286]

Zitat von Dejan Vu:

Bei 20 Installationen ist das kein Zufall mehr. Es scheint doch so zu sein, das es bei allen Installationen auffällt. Ich tippe ja auch auf die Software selbst, aber das muss schon ein merkwürdiger Zufall sein.

Code:

Update Tabelle set Id=5366038 where ....

Gemein ist das in jedem Fall.

DAS ist doch wohl nicht Dein Ernst!
ein

Code:

Insert into Tabelle (id) values(12345)

ginge ja zur not noch aber ein Update auf einen Datensatz der keinen Schlüssel hat??


Gruß
K-H

[Dejan Vu]

Nein, ich meine 'irgendetwas Gemeines'. Also etwas, das richtig fies ist. Gemein. Unerwartet. Zum-Hand-Gegen-die-Stirn-klatschen. Oder-Kopf-gegen-die-Mauer.

PS: Die Tabelle hat ja einen Schlüssel. Das 'Statement' (das es so ja bestimmt nicht gibt) kann ja anders aussehen, z.B.

Delphi-Quellcode:

//Anstatt 
Datensatz.Zahlenfeld := 5366038;
// Steht da eben
Datensatz.Id := BloedeFunktionDie5366038Ergibt();
Datensatz.Post;

Anders kann ich mir das nicht erklären. Oder er überschreibt Field.SetText. Oder. Oder. Oder.

Ärgerlich, sowas.