Prüfe vor Post, ob der Datensatz gesperrt ist

[Ackerjan]

Zitat:

Zitat von HeikoAdams

Vielleicht hilft Dir die CanModify-Eigenschaft von TDataSet weiter:

Zitat:

Gibt an, ob die Datenmenge Schreibzugriffe auf Daten zulässt.

Leider nicht. Habe ich mit als erstes ausprobiert. CanModify gibt mir leider auch true zurück, wenn der Datensatz gesperrt ist.

Zitat:

Wenn CanModify den Wert False hat, kann die Tabelle nur gelesen werden.

Canmodify bezieht sich wohl auf generelle Lese und Schreibrechte.

[Ackerjan]

Zitat:

Zitat von DeddyH

Was ich auf die Schnelle ergooglen konnte, war das Programm onstat. Aber evtl. hilft Dir auch diese Seite schon mal ein wenig weiter.

onstat ist ein Programm was die sysmaster-datenbank von Informix ausliest. Hier speichert Informix auch welche Datensätze gelockt werden. Über die row_id der tabelle, welche im TTable-Objekt nicht verfügbar ist, kann man dann auslesen, welcher Datensatz es ist.

Select kunden where rowid = X führt dann zu dem gelockten datensatz.

Allerdings müßte ich dann in meiner Anwendung eine weitere Datenbankverbindung (sysmaster db) aufmachen, über eine andere systabelle meine tabellen_id bestimmen, dann über die entsprechende Locktabelle die interne rowid der gelockten Datensätze bestimmen und dann könnte ich über ein Select nachsehen ob mein Datensatz dabei ist.. Oder so ähnlich.

[DeddyH]

Was spricht denn dagegen?

[mschaefer]

Moin, moin,

Das Grundproblem liegt eingentlich schon vorher. Ein zweiter User kann den Datensatz bearbeiten während der erste noch in Bearbeitung ist. Gehe davon aus, dass das DBMS den Datensatz vor einem Query.Refresh; auch nicht zuläßt, wenn die Bearbeitung durch den ersten Nutzer abgeschlossen ist. Welcher Isolationlevel wird verwendet?

Grüße // Martin

[Ackerjan]

Hallo Martin

Zitat:

Zitat von mschaefer

Welcher Isolationlevel wird verwendet?

Grüße // Martin

Na, ob ich das beantworten kann?

1. Leider arbeiten wir ohne Transactionen, womit das ein oder andere Sperrenproblem erst garnicht auftauchen würde.
2. Die Datenbank erlaubt Dirty Read auf gesperrte Datensätze.
Also ein Select ist immer möglich.

3. In der 4GL-Sprache nutzten wir deswegen Update-Cursor, welche restriktiver sind und kein dirtyread erlauben und einen Datensatz generell erst versuchen zu sperren. Wird dieser bearbeitet, erfolgt die Fehlermeldung ist bereits gesperrt! Und ein FETCH auf den Cursor wirft einen Fehler :P.

4. Die BDE bietet mir diese Möglichkeit leider nicht. (Glaube ich zumindest).
Nutze ich z.B. ein TTable-Objekt, kann ich ersteinmal die Daten eines gesperrten Satzes ändern. Mit dem folgenden verhalten:

a. Bei einem Post wird dann geprüft, ob sich in der Zwischenzeit die Daten durch einen anderen User geändert haben.
Fehlermeldung: Daten wurden geändert, speichern ist nicht möglich..
b. Oder wie der Fall hier. Gibt die Datenbank an sich den Fehler zurück: Datensatz gesperrt. Die BDE, scheint mir bekommt das garnicht mit!

Es bleibt mir also nichts anderes als mich selber darum zu kümmern. Das DBMS in Verbindung mit der BDE ist mir da wohl keine Hilfe.

[Ackerjan]

Zitat:

Zitat von DeddyH

Was spricht denn dagegen?

1. muss ich zu einer weiteren Datenbank auf dem Server eine Verbindung herstellen.
2. muss ich zwei zusätzliche SQL-Anfragen machen.
Eine auf der Sysmaster
Eine auf der Anwenderdb
3. kann ich mir nicht sicher sein, das Informix in den nächsten Versionen dieselben systabellen hat.

Naja und ich habe gehofft, dass es einfacher geht.

Aber ich habe es ersteinmal so programmiert.

Vielen Dank