Verbindung 1: INSERT, die Sequenz erzeugt ID 15
Verbindung 2: INSERT, die Sequenz erzeugt ID 16
Verbindung 2: INSERT, die Sequenz erzeugt ID 17
Verbindung 1: currval() liefert 15
Verbindung 2: currval() liefert 17
Verbindung 3: currval() liefert einen Fehler -> keine Nutzung bisher in der Verbindung
Was allerdings noch beliebt ist: wenn irgendwelche Trigger greifen und weitere Sequenze Werte verbrauchen. Aber anhand des Beispiels sollte das eher nicht der Fall sein.
Ich denke, Trigger sollten in der Tat nicht das Problem sein. Davon abgesehn nutze ich nicht mal welche.
Ich denke nicht, dass die Sequenzen von Schema 1 und Schema 2 vertauscht wurden, da das fehlerhafte Ergebnis weder zum aktuellen Wert von Schema 1 und 2 passt,Wenn Sequenz Schema A, Nextvalue() 12.000 hat und Nextvalue() 100.000 von Schema B, dann erhalte ich manchmal 7,8,9 (inkrementell). Sonst funktioniert alles wirklich wunderbar.
@ dasblauehandtuch: dein Posting ist komisch … currval arbeitet Verbindungsorientiert.
Kann sein. Ich hatte allerdings mal ein ähnliches Problem, daher bin ich mir relativ sicher, dass curval (aus applikationssicht) nicht auf conncection-basis arbeitet (und das meinte ich), aus datenbanksicht sehr wohl.
Will sagen, je nach db-Abstraction layer kann(!!) es vorkommen, dass z.B. nach einem commit die db-session (dbconnection auf server) geschlossen wird und bereits direkt danach ein curval fehlschlägt.
Allerdings resultierte dies stets ein einem ‘curval noch nicht verfügbar’, falsche werte habe ich noch nie bekommen …