Herausfinden, ob ein Datensatz gesperrt ist und welcher User den Satz sperrt

[Robi]

Wenn ich Sperrungen nur logisch setze, würde ein manuell abgesetztes SQL (z.B. aus dem Navigator heraus) das ja nicht bemerken. Ich müsste dann auch noch bei jedem SQL unsere logische Sperre mitselektieren. Bei physischen Sperren kann ich das jedoch einfach in einer where Klausel machen.
Dieter

Uns wurde vor gefühlten 100 Jahren schon beigebracht:
Wenn Zugriffe auf die Daten außerhalb der WaWi (heute ERP) nötig sind ist die WaWi mist!

Das können wir zwar nicht immer einhalten, finde die Grundidee abr klasse!
Was sprich gegen ein "and XXXjobnr = 0" in allen SQL's?

[dschroeder]

Uns wurde vor gefühlten 100 Jahren schon beigebracht:
Wenn Zugriffe auf die Daten außerhalb der WaWi (heute ERP) nötig sind ist die WaWi mist!

Das können wir zwar nicht immer einhalten, finde die Grundidee abr klasse!
Was sprich gegen ein "and XXXjobnr = 0" in allen SQL's?

Erstmal Danke für die Antwort.

Mir wäre es auch lieber, wenn wir nie von außen an die Datenbanken müssten. Leider lässt sich das nicht vermeiden.

Aber zu deinem "Was spricht gegen ein "and XXXjobnr = 0" in allen SQL's?" Da könnte ich genauso gut fragen: Warum baut ihr eine Sperrlogik selber, die die Datenbank doch schon mitbringt? Ihr wollt ja sperren. Sonst würdet ihr ja keine "weichen" oder "harten" Sperren implementieren. Wenn ihr also sperren wollt: Warum wollt ihr dann, dass eine gesetzte Sperre nicht wirkt? Was anderes ist es meiner Meinung ja nicht, wenn einem eine physische Sperre "zu hart" ist. Es kann aus meiner Sicht nur einen Grund geben: Ihr wollt die gesetzte Sperre im Notfall umgehen können. Bei einer "sauberen" Anwendung dürfte das ja nie passieren. Und in einem Notfall könnte ich einen Job (i.d.R eine interaktive Sitzung), der eine physiche Sperre hält, beenden. Dann ist die physische Sperre weg.

Dieter

[BenderD]

Erstmal Danke für die Antwort.

Mir wäre es auch lieber, wenn wir nie von außen an die Datenbanken müssten. Leider lässt sich das nicht vermeiden.

Aber zu deinem "Was spricht gegen ein "and XXXjobnr = 0" in allen SQL's?" Da könnte ich genauso gut fragen: Warum baut ihr eine Sperrlogik selber, die die Datenbank doch schon mitbringt? Ihr wollt ja sperren. Sonst würdet ihr ja keine "weichen" oder "harten" Sperren implementieren. Wenn ihr also sperren wollt: Warum wollt ihr dann, dass eine gesetzte Sperre nicht wirkt? Was anderes ist es meiner Meinung ja nicht, wenn einem eine physische Sperre "zu hart" ist. Es kann aus meiner Sicht nur einen Grund geben: Ihr wollt die gesetzte Sperre im Notfall umgehen können. Bei einer "sauberen" Anwendung dürfte das ja nie passieren. Und in einem Notfall könnte ich einen Job (i.d.R eine interaktive Sitzung), der eine physiche Sperre hält, beenden. Dann ist die physische Sperre weg.

Dieter

Es gibt da eine einfache eiserne Regel: Eine Benutzertransaktion klammert immer eine Datenbanktransaktion! Sprich: wenn der Benutzer die Steuerung an das Programm zurückgibt, gibt dieses als erstes alle Satzsperren frei. Wenn ich denn nun länger dauernde Transaktionen habe, komme ich um logische Sperren nicht drumherum (das kann man sich gut an einem Flugreserverungssystem klar machen). Bei Lichte betrachtet gibt es von letzterer Sorte nicht viele Anwendungsfälle, meist steckt da krummes Anwendungsdesign dahinter (siehe Dein Beispiel mit dem Kundensatz!).

D*B