Eigenartiger Effekt mit int-Primary Keys ?

[Dejan Vu]

Zitat von gmc616:

Das dieser Effekt/Bug tatsächlich existiert haben ich live gesehen!
Geschrieben ist das Ganze im VS2010 in der afxdb.h

Der Bezug zu ADO fehlt mir hier und deine Interpretation im Eingangspost ist eindeutig falsch. Du verwechselst RFX mit SQL-Server. Und selbst wenn -aus welchen Gründen auch immer- ein 'UPDATE tabelle SET id=ABS(id)*-1 WHERE id =NULL;' ausgeführt werden würde, würde rein gar nichts passieren. Daran (also am Schlangenöl) kann es also nicht liegen.

Zitat:

Zitat von Dejan Vu:

Vorschläge habe ich nicht, nur drei Fragen:
1. Wie markierst/löschst Du Fremdschlüssel?

Was verstehst du unter Fremdschlüssel? Hier gibt es nur Primary Keys und die gehören alle "mir".

Du scheinst nur rudimentäres Grundwissen über Datenbanken zu haben. Daher auch dein Glaube an Schlangenöl.

Zitat:

Zitat von Dejan Vu:

3. Welchen transaction Isolation level verwendest Du?

Gute Frage! Was passiert denn, wenn man TAdoConnection.BeginTrans ruft?

Auch hier erkennt man dein fehlendes Wissen.
Um diese Frage zu beantworten, verwende den Profiler, oder schau Dir die Eigenschaften der Connection an. Wenn Du weißt, wie der Isolationlevel ist, dann weißt Du auch, wie sich der Server beim konkurrierenden Lesen verhält.

Natürlich ist das ärgerlich und irgendwo ist der Wurm. Aber ich lege meine Hand ins Feuer, das der SQL-Server mit NULL-Werten richtig umgehen kann.

Zeig doch mal die Definition der Tabelle mit den doppelten Ids. Wichtig ist auch die Definition vom Index sowie die Definition der 'idents-Tabelle'.
Beim SSMS gibt es die Funktion 'Generate Script'. Dort musst Du dann die eine Tabelle auswählen und in den Eigenschaften (ein Button auf der 3. Seite) noch einstellen, das auch der Index geskriptet werden soll. Das stellst Du dann hier ein und dann schauen wir weiter.

Du kannst versuchen, dein Updatestatement sicher zu machen, indem Du die 'OUTPUT' Klausel verwendest (obwohl Du damit nicht mehr kompatibel zu dBase bist).

Code:

UPDATE nidents 
   SET id=id+1 
OUTPUT id
 WHERE tbname=:TableName 
   AND idname=:PkName;

Damit hast Du eine atomare Anweisung, die garantiert transaktionssicher ist. Allerdings sind Probleme aufgrund der Nebenläufigkeit i.a. zufälliger Natur, d.h. Du müsstest eher zufällige doppelte Schlüssel beobachten.

Auch wenn es zum Haareraufen ist: Meist sitzt der Fehler 80cm vom Bildschirm entfernt.

Nebenbei: Wer will heutzutage noch kompatibel zu dbase sein, wo es doch freie Datenbanken gibt?

[p80286]

Zunächst einmal, alle Schlüssel dienen der internen Verwaltung von Daten. Wer von extern darauf zugreift und diese manipuliert gehört geteert und gefedert.
Was deinen Fehler angeht, wenn der/die Schlüssel bereits existieren, dann arbeitet Dein Schlüsselgenerator eben nicht zuverlässig, da das nicht auftreten darf.

Was heißt überhaupt negativ setzen? id:=id*-1 oder id:=id or $F000000 ?
Und wieviele Bits haben Deine Integers eigentlich? Wenn auch DBase versorgt werden muß, konnte das eigentlich schon mit 32Bit-Werten umgehen?

Gruß
K-H

[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