Interbase Update sperren realisierem

[Albi]

Hallo,

ich möchte für die Interbase eine Updatesperre basteln und weiß nicht genau wie das am besten realisieren kann.

Mein Ausgangspunkt ist bis jetzt, dass ich ein eine Eingabemaske habe. Sobald der User einen gesuchten Eintrag gefunden hat, sind die Edits enable = False. Wenn nun der User auf den Bearbeitung Btn klickt werden die Edits enable = true und er kann die Daten bearbeiten. Soweit ist das auch kein Problem.

Ich will nun aber, dass der DS sobald ein User diesen Bearbeiten will für alle anderen user gesperrt wird bzw. nur gelesen werden kann.

Nun habe ich hier im Forum von einer Sperrtabelle oder simulierten Updates gelesen und nun habe ich gefragt ob es da noch eine andere Möglichkeit gib.

[Jens Schumann]

Hallo,
der Interbase/Firebird arbeitet mit einer Multigenerationenarchitekur MGA Interbase.
Da werden keine Locks unterstützt.

Wenn in der Zwischenzeit ein anderer User den Datensatz geändert hat könntest Du wie folgt darauf reagieren:
Wenn Du eine Tabelle mit Vor- und Nachnamen hast könntest Du das Update folgendermaßen
realisieren

SQL-Code:

UPDATE tabelle SET vname='Delphi', nname='Praxis' WHERE (vname=alter_vorname) and (nname=alter_nachname)

alter_vorname und alter_nachname stehen für die Werte, die beim Lesen des Datensatzes aus der Datenbank gekommen sind. Wenn jetzt ein anderer User den Datensatz geändert hat, geht das Update schief. Dann könntest vom User bestätigen lassen ob der inzwischen geänderte Datensatz überschrieben werden soll.

[Albi]

Das ist mir schon klar gewesen, dass es die Sperrmechanismen bei Interbase gibt, nutze ich auch.

Aber ich will halt, dass der DS bereits beim klicken auf Edit eine Sperre erhält und nicht erst wenn die Transaction gestartet wird.

Beim Klick auf Edit werden nur die Edit enable = true gesetzt, somit weiß die DB aber noch nicht, dass der DS gerade bearbeitet wird. Aber das genau will ich der DB auf irgendeine Art&Weise mitteilen.

[Robert_G]

Eine Mögichkeit wäre sicher Firebirds event system (User X ändert etwas -> Clients von User Y & Z werden benachritigt)
Aber alles was man da auch basteln kann ist in einer simplen C/S Architektur nur Rumgebastel. ;)
Wirklich konsistent kannst du sowas IMHO nur mit einer MiddleTier lösen. ;)

[Albi]

Das wäre für diese Anwendung doch ein wenig hochgegriffen. Da lasse ich es lieber so wie es ist und es gib ne Meldung für darüber, dass der DS bereits von einem anderem User geändert wurde.

[proitsystems]

der aktuelle Firebird unterstützt doch die Anweisung "SELECT .... FOR UPDATE". Damit werden die Daten gelockt. Bevor das Dataset in den Editmode geht könnte man auf der gleichen Transaktion dieses SELECT Statement ausführen.

Eine andere Möglichkeit wäre (bevor das Dataset in den Editmode geht) ein Pseude Update zu fahren (UPDATE Tabelle SET Feld = Feld WHERE ID = x). Natürlich in der gleichen Transaktion.

Beim Commit oder Rollback ist das Lock dann wieder aufgehoben.


Gruss,

Marc
----
PRO IT SYSTEMS

[Albi]

Zitat:

Zitat von proitsystems

der aktuelle Firebird unterstützt doch die Anweisung "SELECT .... FOR UPDATE". Damit werden die Daten gelockt

Vielen Dank, diese Variante werde ich mal versuchen.

Nur so zur Sicherheit. Die Anweisung sollte dann im ganzen so in etwa aussehen

SQL-Code:

select ID From DB WHERE ID = :iID For Update

[mschaefer]

Hier mag ich nochmal nachhaken:

Das ein User einen gerade in Bearbeitung befindlichen Datensatz nicht bearbeiten kann
ist bei Delphi mit FB eine reine Katastrophe im Gegenatz zu Oracle-Forms-Anwendungen
wo dies mit einer Selbstverständlichkeit völlig automatisch realisiert ist.



Möglichkeit für einen einzelnen Datensazt:

- Dummy edit und Post -> Error, dann gelocked


Möglichkeiten in einem Grid als momentan Anzeige darzustellen welche Datensätze gerade gelockt sind:

- Für jeden Datensatz duchgehen: Dummy edit und Post -> Error, dann gelocked


Erstaunlich ist allerdings, das sowas noch nicht in eine erweiterte Query-Komponente eingebauet worden ist.
Denn letzlich geht es doch nur darum beim umstellen auf 'edit' gleich einen 'post' zusenden. Kommt dann keine
Fehlermeldung wird wieder auf 'edit' geschaltet, andernfalls bleibt es im 'browse' Mode.


Grüße // Martin

[mkinzler]

Zitat:

as ein User einen gerade in Bearbeitung befindlichen Datensatz nicht bearbeiten kann
ist bei Delphi mit FB eine reine Katastrophe

Wie meinst du das? Änderungen in eine Tranaktion sind für andere Transaktionen doch nicht sichtbar. Und welchen Sinn würde eine parallele Änderung machen ( würde das ganze Transaktionsprinzip adabsurdum führen).
Ich kann mir nicht vorstellen, das dies bei Oracle anders ist.

[mschaefer]

Moin, moin,

Wenn man da ein Grid hat gibt es banal Zeilen die sind nicht zu ändern und andere eben doch.

Es da ganz einfach so, dass Datensätze die in Bearbeitung nur zum lesen für andere im Zugriff sind. Man kann nicht in den Editmodus gehen. Das scheint mir auch sinnvoll, denn wenn der zweite Nutze erst am Ende seiner Eingaben erfährt, dass er sie nicht speichern kann, dann hat er da banal Zeit reingesteckt und eventuell auch Daten verloren.

Grüße // Martin

[mjustin]

Zitat:

Zitat von mschaefer

Moin, moin,

Wenn man da ein Grid hat gibt es banal Zeilen die sind nicht zu ändern und andere eben doch.

Es da ganz einfach so, dass Datensätze die in Bearbeitung nur zum lesen für andere im Zugriff sind. Man kann nicht in den Editmodus gehen. Das scheint mir auch sinnvoll, denn wenn der zweite Nutze erst am Ende seiner Eingaben erfährt, dass er sie nicht speichern kann, dann hat er da banal Zeit reingesteckt und eventuell auch Daten verloren.

Grüße // Martin

FireBird kennt eine SELECT ... WITH LOCK Klausel für das pessimistische Locking von Datensätzen:

[Understanding the WITH LOCK clause]
http://www.firebirdsql.org/refdocs/l...-withlock.html

Der zweite Benutzer hat im Prinzip auch bei Verwendung dieser Option seine Daten 'verloren', falls er sie nicht anders speichert, z.B. auf einem Zettel ;-)

Man kann aber zu Beginn der Bearbeitung ein Dummy-Update versuchen, und so sofort (anhand der Exception) erkennen, dass der Satz in Bearbeitung ist, z.B. ein UPDATE FOO SET LAST_MODIFIED=CURRENT_TIMESTAMP WHERE ID=:ID Wenn keine Exception auftritt, darf die Anwendung in den Edit-Modus gehen, die Eingaben sind gegen Verlust sicher.

[mkinzler]

In den meissten Fällen macht MGA bei FireBird explizite Sperren unnötig. Manchmal benötigt man diese aber doch, deshalb wurde der explizite Lock in FB 1.5 eingeführt.

[mschaefer]

Ja der Bedarf ist schon da. Wieso es aber nicht mit einer Select-Anweisung möglich ist nach aktuell gesperrten Sätzen zu suchen, das ist mir irgendwie ein Rätsel. Bei einem Dummy-Update muß ich jedesmal noch Daten senden um die Mitteilung zu bekommen geht nicht. Eigentlich fehlt mir sogar noch was mehr. Ein Hinweis Du ich habe den Datensatz bis in 5 Minuten in Bearbeitung, lass mich solange in Ruhe. So eine Art Buchleihe System wie in der Bibliothek, wo man eventuell sogar verlängern kann oder man muß den Record rausrücken, wenn er angefordert ist. Da muß man wohl doch was eigenes bauen..

Grüße // Martin

[mkinzler]

Sowas könnte vielliecht mit Hilfe der Monitoring Erweiterungen von FireBird 2.1/2.5 möglich sein
http://blog.upscene.com/thomas/index...y080730-135908

[mschaefer]

Ja das könnte mal interessant werden. Bis dahin muß ich mich doch mal um eine eigene TQuery kümmern...

Einen guten Sekt ins neue Jahr // Martin