nicht angemeldet
Hallo Selferinnen und Selferaußen,
dazu möchte ich doch mal meinen Senf ablassen, bevor es zu spät ist.
Wenn man so vorghet, wie hier oberflächlich beschrieben, dann braucht man gar keine Datenbank anzulegen, denn es findet sich bestimmt jemand, der ALLE Datensätze löscht. Solche Aufgaben sollte man nicht ohne Session lösen.
1. Schritt
kein Datensatz ist ausgewählt. Sessionpuffer für Datensätze (Array) ist leer.
2. Schritt
Datensatz wird angefordert. Es wird eine ID erzeugt und unter dieser ID in das Array in der Session eingetragen. Die Satzdaten zusammen mit der ID (hidden) ausliefern Nun kann man eindeutig identifizieren, dass genau dieser Datensatz zur Bearbeitung an DEN angemeldeten Benutzer (Session-ID) ausgeliefert wurde.
3. Schritt (a)
der User entscheidet sich, den Satz am Client zu ändern und dann zum Update zurückzuposten. In der Session nachschauen, ob ein Satz unter dieser ID mit der Satznummer eingetragen ist. Nun kann man noch feststellen, welche Felder verändert wurden und daruas Trigger ableiten, ggf. einen Dialog mit dem User anzetteln...
Der Satz wird in der DB updated und dann ggf. aus dem Sessionpuffer entfernt. Damit sind auch Doppelpostings abgefangen. Es ist NICHT möglich, Sätze zu verändern, die vorher nicht eingetragen worden sind.
3. Schritt (b)
...
Löschen fünktioniert natürlich analog. Es ist dadruch nicht möglich, durch Formular-Manipulation beliebige Sätze zu löschen.
Ob man nun immer auch die Daten des Datensatzes oder nur die Schlüssel (Formular-ID, Satznummer) in der Session abspeichert ist Philosophie. Man kann dafür natürlich eine eigenständige Tabelle benutzen, die
ID_User, Sessionnr, Tabellenname, Satznummer, Dirtyflag(s), Readyflag, Timestamp, ...
enthält.
Dann kann man damit sehr leicht ein Managementsystem für konkurrierende Zugriffe inclusive Logging (wer hat wann welchen Satz angefordert, bearbeitet, gelöscht,...) bauen. Ist fast kein Aufwand mehr.
Liebe Grüße
Chris (C)