Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Datenbanken (https://www.delphipraxis.net/15-datenbanken/)
-   -   Delphi Prüfe vor Post, ob der Datensatz gesperrt ist (https://www.delphipraxis.net/119368-pruefe-vor-post-ob-der-datensatz-gesperrt-ist.html)

Ackerjan 25. Aug 2008 15:46

Datenbank: Informix • Version: 10 • Zugriff über: Borland Database Engine

Prüfe vor Post, ob der Datensatz gesperrt ist
 
Hallo,

ich habe das folgende Problem:

Ein Teil der Anwendungsumgebung in der ich programmiere nutzt eine nicht sehr verbreitete 4GL-sprache. Will man in dieser Sprache einen Datensatz bearbeiten nutzt man einen Update-Cursor. Dieser sorgt dafür, dass ein Datensatz auf der Informixdatenbank explizit gesperrt wird, während man damit arbeitet.

Nun will ich auf der Tabelle über ein TTable-Objekt mehrere Datensätze mit meinem Delphiprogramm ändern. Das klappt solange, bis ich ein Post auf den gesperrten Satz mache.(logisch).

Nun meine Fragen.

Gibt es eine "einfache" Möglichkeit vorher zu erfragen, ob der Datensatz gesperrt ist?
Kann ich den exclusiven Zugriff auf einen bestimmten Datensatz erzwingen (Nicht die ganze Tabelle sperren!)?
Oder kann ich zumindest gezielt in einem try except -Block den Informix-Fehler abfangen?
Oder könnt Ihr mir irgendwie anders weiterhelfen?


Der folgende Versuch lieferte leider nicht den richtigen Fehler!
-107 = [ISAM error: record is locked.] Diese wurde zwar in der EDB.Message als unknown error message number '-107' angezeigt. Der NativeErrorCode war leider falsch (-243).

except
on EDB: EDBEngineError do
begin
for i := 0 to EDB.ErrorCount -1 do
begin
if EDB.Errors[i].NativeError = -107 then
probiere_es_nochmal;
end;
end;

Anmerkung: Ich arbeite mit der BDE und Informix.

mkinzler 25. Aug 2008 15:57

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Warum BDE?

SubData 25. Aug 2008 16:15

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Zitat:

Zitat von mkinzler
Warum BDE?

Sehr hilfreich...

Dieses BDE-Bashing nervt... :wall:

mkinzler 25. Aug 2008 16:17

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Gern geschehen.

Bernhard Geyer 25. Aug 2008 16:21

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Zitat:

Zitat von SubData
Zitat:

Zitat von mkinzler
Warum BDE?

Sehr hilfreich...

Dieses BDE-Bashing nervt... :wall:

Ein Teil seiner Probleme liegen höchstwahrscheinlich in der BDE begründet (Fehlerhaftes Fehlermapping). Und wenn es erste Gehversuche mit einem praktisch in der Entwicklung gestorbenen System handelt dann sollt man dieses Hinterfragen.

Ach ja. Wieso hilfst du nicht? Dieses BDE-Bashing-Bashing ohne selbst zu helfen nervt :wall: :wall:

Ackerjan 25. Aug 2008 16:28

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Warum BDE ist einfach beantwortet! Weil es hier seit sehr langer Zeit eingesetzt wird!
Der Umstieg auf ADO, das umprogrammieren der Komponenten usw. wird wohl ein neues Projekt :).

Frage bezeiht sich also auf die BDE!

SubData 25. Aug 2008 16:32

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Zitat:

Zitat von Bernhard Geyer
Ach ja. Wieso hilfst du nicht? Dieses BDE-Bashing-Bashing ohne selbst zu helfen nervt :wall: :wall:

Einfach zu beantworten: Weil ich es an dieser Stelle nicht kann.
Ich wollte ihn auch nicht persönlich angreifen, aber es ist nunmal sehr "anstrengend" in jedem Thread über/mit BDE zu lesen, dass die BDE tot ist und jeder 3. fragt erstmal nach, warum denn nicht DatenbankTreiberXYZ verwendet wird.

Natürlich ist die BDE tot. Das wissen auch eigentlich alle.
Aber die Leute, die damit noch arbeiten (müssen) werden schon ihre Gründe haben und ich finde es einfach nicht richtig jedem gleich an den Kopf zu werfen, dass er gefälligst die BDE weglassen soll (Was ggf. 1000e Stunden Arbeit bedeuten würde).

Tschuldigung fürs OT und tschuldigung, falls sich jemand angegriffen gefühlt hat!

HeikoAdams 25. Aug 2008 16:32

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Vielleicht hilft Dir die CanModify-Eigenschaft von TDataSet weiter:
Zitat:

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

SubData 25. Aug 2008 16:34

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Zitat:

Zitat von HeikoAdams
Vielleicht hilft Dir die CanModify-Eigenschaft von TDataSet weiter:
Zitat:

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

Die Daten sind doch aber änderbar, auch wenn der Datensatz gesperrt ist.
Sie können nur in dem Moment nicht zurück in die Datenbank geschrieben werden.

Oder sehe ich das falsch ?!

DeddyH 25. Aug 2008 16:36

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Was ich auf die Schnelle ergooglen konnte, war das Programm onstat. Aber evtl. hilft Dir auch diese Seite schon mal ein wenig weiter.

Ackerjan 25. Aug 2008 16:54

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
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 25. Aug 2008 17:10

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
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 25. Aug 2008 18:53

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
Was spricht denn dagegen?

mschaefer 25. Aug 2008 20:07

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
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 26. Aug 2008 12:19

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
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 26. Aug 2008 15:32

Re: Prüfe vor Post, ob der Datensatz gesperrt ist
 
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


Alle Zeitangaben in WEZ +1. Es ist jetzt 17:02 Uhr.

Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz