![]() |
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. |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Warum BDE?
|
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Zitat:
Dieses BDE-Bashing nervt... :wall: |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Gern geschehen.
|
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Zitat:
Ach ja. Wieso hilfst du nicht? Dieses BDE-Bashing-Bashing ohne selbst zu helfen nervt :wall: :wall: |
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! |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Zitat:
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! |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Vielleicht hilft Dir die CanModify-Eigenschaft von TDataSet weiter:
Zitat:
|
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Zitat:
Sie können nur in dem Moment nicht zurück in die Datenbank geschrieben werden. Oder sehe ich das falsch ?! |
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
![]() |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Zitat:
Zitat:
|
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Zitat:
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. |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Was spricht denn dagegen?
|
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 |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Hallo Martin
Zitat:
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. |
Re: Prüfe vor Post, ob der Datensatz gesperrt ist
Zitat:
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