Record-Lock mit SQL

[BenderD]

Unter dem passenden Commit Level wird der Satz auch beim select into gesperrt. Schau Dir mal die Commit Level Einstellungen an.
BTW: Einsatz von SQL ohne Commit Steuerung ist ein ernsthafter Designfehler, das machen nur Wahnsinnige und/oder Ahnungslose!!! Und der Einsatz von Journaling ist auch ohne Einsatz von Commit von großem Nutzen!!!

D*B

Tja, erstmal vielen Dank für die zahlreichen Antworten. Ich muss zugeben, dass ich immer noch nicht so genau weiß, was der beste Weg ist. Ist es nicht so, dass man für Commitment Control Journaling braucht? Das hatten wir bisher nicht auf allen Tabellen. Aber jetzt wird bei uns gerade ein iCluster aufgesetzt und damit bekommen wir das flächendeckend. Birgitta hat genau erkannt, was wir wollen: Ein simpler chain mit dem Primärschlüssel und einige Zeit später (nachdem der User etwas editiert hat) ein Update (oder Unlock auf dem Datensatz). Die meisten anderen Zugriffe machen wir bei uns bereits per SQL. Bei dem oben beschriebenen Problem würden wir am liebsten gar keinen Cursor definieren und den Satz mit fetch einlesen. Stattdessen würden wir gern mit "Select * into " arbeiten. Wir wissen ja, dass wir nur genau einen Datensatz lesen werden (Primärschlüssel im where).

Wenn noch jemand einen guten Gedanken hat, immer her damit. Ansonsten werde versuchen, nochmal ein wenig in der Literatur zu stöbern.

Vielen Dank soweit.

Dieter

[camouflage]

@Birgitta
Bin ganz bei dir, dachte nur ich stell das Ganze ein bisschen strukturierter dar.

Und bzgl. des Pointers war ich wohl etwas abwesend, meinte natürlich schon den Cursor.

[Fuerchau]

@Andreas
Mehrere Updates bleiben nur gesperrt, wenn man unter CommitControl arbeitet.
Satzsperren aller Aktionen bleiben dann bis zum Commit/Rollback erhalten.
Dies geht auch über einen Close hinaus.

[andreaspr@aon.at]

@Andreas
Mehrere Updates bleiben nur gesperrt, wenn man unter CommitControl arbeitet.
Satzsperren aller Aktionen bleiben dann bis zum Commit/Rollback erhalten.
Dies geht auch über einen Close hinaus.

Das stimmt wenn du ein einfaches UPDATE durchführst.
Jedoch im angegebenen Beispiel sperrt der Cursor den Satz.
(siehe auch Kommentar von Birgitta)

[Fuerchau]

Du meintest also mehrere Updates auf dem selben Satz.
Aber auch SQL verlangt nach einem Update einen neuen Read / Fetch, da ein Update die Sperre (ohne CommitControl) wieder aufhebt, da ein "Update current" ohne Read nicht geht.

[andreaspr@aon.at]

Du kannst es mal ausprobieren.
Nach dem Update ... where current of ... ist der selbe Satz immer noch gesperrt.
Erst nach einem fetch oder close wird der Satz endgültig freigegeben.
(Alles ohne Commitment Control)