Frage zu Datensätzen und Speichern in der Datenbank

Hallo zusammen,

was passiert eigentlich wenn ein Datensatz aus der Datenbank an zwei verschiedenen
Rechnern bearbeitet wird und die User nahezu gleichzeitig die Daten wieder in die
Datenbank speichern wollen?

Meine Überlegung ist dass der Datensatz der zuletzt bei der Datenbank ankommt auch
übernommen wird

Die zweite frage wäre was passiert wenn ein Benutzer einen Datensatz lädt und dann
seinen Rechner in den Ruhezustand schickt. Kann der Benutzer dann den Datensatz
wieder speichern? Muss man die Verbindung wieder neu aufbauen und die Daten
aktualisieren?

Hi,

zu deiner ersten Frage:
Das hängt ganz davon ab, wie weit du den Datensatz sperrst. Wenn du ihn völlig ungesperrt lässt, dann kann folgendes passieren: Beide Nutzer holen sich den Datensatz in ihren Rechner und ändern ihn. Nutzer 1 schreibt als erster seine Änderungen zurück. Nutzer 2 schreibt als zweiter seine Änderungen zurück und überschreibt dabei die geänderten Felder von Nutzer 1 (weil Nutzer 2 ja noch die Originaldaten abgeholt hatte, bevor Nutzer 1 sie änderte).

Deswegen sperrt man eigentlich Datensätze zur Bearbeitung. Dafür gibt es mehrere unterschiedlich restriktive Level. Ich kenne üblicherweise die Sperrung, bei der man einen Datensatz, den ein anderer Nutzer gerade in der Mache hat, zwar lesen, aber nicht bearbeiten kann. Dann ist das oben beschriebene Szenario ausgeschlossen, allerdings musst du den Datensatz nach Freigabe durch den Fremdnutzer nochmal aufrufen, damit du den aktuellen Zustand hast.

Frage 2 hängt nach meiner Meinung von der Realisierung der Frage 1 ab. Aber das wissen andere wahrscheinlich besser.

Liebe Grüße
Marz

Die Stichwörter nach denen du suchst heissen:

Optimistic Locking
Pessimistic Locking

Einfach danach googeln und tonnenweise Artikel lesen.

Hier im Forum gabs vor ein paar mal eine sehr aufschlussreiche Diskussion darüber, den ich aber gerade nicht finde.

Hallo,

Zu 1)
ein recht einfaches Verfahren ist es, eine Version des Datensatzes mitzuführen. Wenn Nutzer A und B die Daten sich ziehen, ist diese in dem Moment gleich. Ändert A jetzt was und speichert den Datensatz, dann wird die Version um eins hochgezählt. Speichert B jetzt, stimmt seine Version nicht mehr mit der Version des Datensatzes in der DB zusammen und kracht weg. Man kann auch anstatt der Version ein einfachen Timestamp nehmen. Das funktioniert natürlich auch.

Zu 2)
Ja natürlich sollte er ihn noch speichern können. Die Daten sind ja lokal jetzt auf dem Client. Und die Verbindung muss eh immer erst aufgebaut werden, wenn man sie braucht.

...Deswegen sperrt man eigentlich Datensätze zur Bearbeitung. Dafür gibt es mehrere unterschiedlich restriktive Level. Ich kenne üblicherweise die Sperrung, bei der man einen Datensatz, den ein anderer Nutzer gerade in der Mache hat, zwar lesen, aber nicht bearbeiten kann. Dann ist das oben beschriebene Szenario ausgeschlossen, allerdings musst du den Datensatz nach Freigabe durch den Fremdnutzer nochmal aufrufen, damit du den aktuellen Zustand hast....

Wenn Du Dir die Daten in ein DataSet lädst und anschl. die Verbindung trennst, wie willst Du dann den Datensatz, den Du im DS bearbeitest sperren? Was Du mit den Daten machst, nachdem Du sie ins DS geladen hast, davon 'weiß' die Datenbank nichts. Das Dir ein anderer Nutzer in die Quere gekommen ist, merkst Du erst, wenn Du Deine eigenen Änderungen zurückschreiben willst und dann musst Du sehen, wie Du darauf reagierst.

@MarzAttak:
Genau das macht man unter .NET eben nicht.
DotNet verfolgt das Disconnected Konzept mit optimistic Locking, hier werden keine Datensätze gelockt, sondern beim schreiben geprüft ob sich Änderungen ergeben haben.

@ProGamer:
Das sind absolute ADO.NET Grundlagen.
Wenn du mit einem DataSet arbeitest und den DataAdapter per CommandBuilder mit den entsprechenden Commands versorgst wird vor jedem Speichern geschaut ob Änderungen sind, wenn ja bekommst du eine ConcurencyException.
Du kannst auch eine TimeStamp Column( nicht verwechseln mit DateTime ) benutzen.
Willst du explizit das Überschreiben erlauben, musst du dies im CommandBuilder einstellen.
Und zu 2. Da man niemals eine Connection für die Gesamte Programmlaufzeit aufrechterhält, erübrigt sich doch die frage, oder?
Und natürlich macht es sinn den Datensatz neu zu laden, aber das kommt ja auf den Anwendungsfall an.

Das erste Problem nennt man Lost Update, daneben gibts noch Dirty Read, Non-Repeatable Read und Phantom Read. Dazu findet man leicht Erklärungen und Lösungen.

@Humsch

Stimmt... war von der Datenbank her gedacht, wo das sehr wohl möglich ist (bspw. Access).

Vielen Dank an alle soweit

Da sind ja einige Stichworte zusammengekommen und die Empfehlungen scheinen in eine Richtung zu gehen.
Ich werde mal mit den DataSets und DataAdapter etwas herumexperemtieren und schauen was so bei rum kommt

Ich habe in der MSDN etwas hilfreiches gefunden

How to: Enable Optimistic Concurrency Checks

Danke an alle die geantwortet haben!