Datensatz n - m zurückliefern, nicht die kompletten Daten

[Falk Prüfer]

Hallo Micha,

<i>soll heißen, wenn Nutzer B Datensätze in sein FrontEnd laden möchte, sagen wir 100, und Nutzer A macht gerade im Satz 33 rum, dann bekommt Nutzer B diese ORA Exception gefeuert und somit keinen einzigen Datensatz zurück?</i>
Wenn die Abrage der 100 DS mit FOR UPDATE NOWAIT gestartet wurde, dann ja!
Die gewünschte Logik mußt du schon selbst implementieren. Also 100 DS "normal" Abfragen für die Liste und wenn der User an einem dvon "rummachen" will, dann nochmal explizit diesen einen Satz mit einem FOR UPDATE NOWAIT abfragen. Damit stellst du sicher, das der User die aktuellen Daten in die Eingabmaske bekommt und kein anderer diese Daten mehr ändern kann, solange sie nicht gespeichert (COMMIT) oder verworfen (ROLLBACK) sind.

Gruß Fal

[Achim]

Ja hallo nochmal...

Bisher sind mir zwei verschieden Techniken untergekommen:
1: beim Update der Datensatze werden expliziet alle selektierten Felder in die where-Bedingung mit ihren ALTEN Werten übernommen.
2. Die von Falk beschriebene.

Ich glaube .Net generiert automatisch Ansatz 1. .
Der ist wirklich nicht schön.

Der zweite wird z.B. von Forms implizit verwendet und lässt sich relativ leicht in Delphi oder C# implementieren:

1:Select inclusive der Rowid
2:ON-Record/Fieled-Change Event
Select * from table
where rowid = :myRowid for update
nowait.
und exception handling
"Daten wurden von anderem User geändert".

Gruß Joachi

[Micha80]

Guten Tag,

Nachfrage zum Thema UPDATE NOWAIT.

Nehmen wir an, Nutzer A zieht sich die Daten mittels SELECT .... FOR UPDATE NOWAIT in die Eingabemaske, macht aber nie eine Update, sondern einfach das Browserfenster zu. Wann oder Wie bekommt die DB das mit, dass die mittels FOR UPDATE NOWAIT gesperrten Datensätze wieder freigegeben werden könnten - gibts da ein Timeout?

Danke für die Info, Michae

[Micha80]

Hallo Forum,

meine obige Frage ist noch aktuell :-) Dank

[Falk Prüfer]

Hallo Micha,

eine gut programmierte Anwendung sollte beim Beenden einen expliziten Logout vornehmen. Beim Logout werden dann durch die DB alle offenen Transaktionen zurückgerollt (ROLLBACK) und damit die Sperren aufgehoben. Wird die Anwendung "abnormal" beendet und die Session bleibt bestehen, dann bleiben auch die Sperren erhalten. Normalerweise "merkt" der ORACLE-Server irgendwann, daß die Session tot ist - es hängt ja kein Client mehr dran - und versucht sie zu beenden. Das kann aber u.U. ein paar Stunden dauern. Ansonsten muß der Admin eingreifen und die Session mit ALTER SYSTEM KILL SESSION per Hand beenden.
Da ich in deiner letzten Frage aber das Wort Browserfenster gelesen habe - in einer Browserbasierten Applikation sind die Rules noch etwas anders. Da keine persistente Verbindung zwischen Client (der Browser des Nutzers) und Server besteht kannst du auch keine permannenten Sperren setzen! Der DB-Client ist hierbei ja der WebServer und die DB-Verbindung wird über ein Script (z.B. PHP) hergestellt. Evtl. gesetzte Sperren bestehen dabei nur solange wie das Script "läuft". Hat der WebServer die Ausgabe als HTML an den Browser abgeschickt, wird die DB-Session automatisch beendet und damit auch alle Sperren aufgehoben.

Gruß Fal

[Alexander Fischer]

probier doch mal
select * from table where Id >4 and where Id<20

[Falk Prüfer]

Hallo Alexander,

<i>select * from table where Id >4 and where Id<20;</i> setzt aber voraus, das die ID fortlaufend und vor allem lückenlos ist!
In einer "lebenden" Tabelle ist es sehr schwer, diese Id lückenlos zu halten. Bei jedem gelöschten DS werden statistisch gesehen die Hälfte aller DS "neugeordnet"!

Gruß Fal