![]() |
Datenbank: Ms Sql Server • Version: 2000 • Zugriff über: Ado
Gleichzeitige Änderung des Datensatzes am anderen PC
Hallo!
Angenommen, ich lasse mir mit meinem Programm gerade einen Datensatz anzeigen aus der DB, und zum gleichen Zeitpunkt wird dieser Datensatz an einem anderen PC geändert. Dann stimmen die mir angezeigten Daten natürlich nicht mit dem Bestand überein. Was macht man in so einer Situation, kann ich irgendwie davon erfahren, dass dieser Datensatz geändert wurde ? Ich benutze die Ado-Komponenten für die Verbindung zum Ms Sql Server. Dankeschön schonmal für eure tolle Hilfe! Gruß, Andy |
Re: Gleichzeitige Änderung des Datensatzes am anderen PC
Es gibt mehrer Möglichkeiten sowas zu erkennen/verhindern/umgehen:
1, Implementier einen Server übern den alle Aktionen laufen (3Tier-Architektur) 2, Definier eine LastChange-Spalte die du vor dem Post prüfst bzw. in's update mit verwendest 3, Definier eine Sperrtabelle in der Anwendungen DB-Einträge welche zum ändern gesperrt werden sollen eingetragen werden 4, Fordere die Datensätze zum Update an (AFAIK mit der Syntax "SELECT ... FOR UPDATE") Jede der Lösungsansätze hat vor und Nachteile |
Re: Gleichzeitige Änderung des Datensatzes am anderen PC
Hallo,
danke! Den 4. Punkt finde ich sehr interessant. Das heißt, der Datensatz wird durch SELECT FOR UPDATE solange gesperrt, bis ich ein Commit mache? Das ist doch schonmal was. Vielleicht kann ich so mein eigentliches Problem genauer beschreiben: Ich kann in meiner Anwendung z.B. eine Kundenliste mehrmals gleichzeitig öffnen. Wenn ich aus der einen Liste einen Kunden lösche, möchte ich natürlich, dass er aus den anderen Listen ebenfalls verschwindet. Muss ich das Programm-Intern lösen und gibt es dafür was von der Datenbank? |
Re: Gleichzeitige Änderung des Datensatzes am anderen PC
Zitat:
|
Re: Gleichzeitige Änderung des Datensatzes am anderen PC
Ich würde so etwas nicht über eine Sperre realisieren.
In einem gut strukturierten Betrieb wird es wohl sehr selten zwei Personen geben, die die gleichen Daten eines Datensatzes ändern. Bei Kundenstammdaten wird die Adresse z.B. sehr selten von zwei Personen gleichzeitig verändert, aber vielleicht ändert der eine die Adresse und der Andere die Bankverbindung. Man sollte ein Reconcile in Erwägung ziehen. Du lädst Dir einen logischen Datensatz, Das ist Version 1. Der Anwender ändert ihn und will ihn speichern. Das ist Version 2. Vor dem Speichern lädst Du den Datensatz nochmal. Das ist Version 1a. Unterschiede zwischen V1 und V2 hat der Anwender vorgenommen. Nennen wir die gemachten Änderungen A1. Unterschiede zwischen V1 und V1a haben ANDERE Anwender vorgenommen. Diese Änderungen nennen wir A2. In den Fällen, in denen A1 und A2 disjunkt sind, kann man getrost die Änderungen in V2 abspeichern, denn die tangieren in keinem Fall die vorherigen Änderungen. Nur wenn es Felder gibt, die sowohl in A1 als auch in A2 sind, haben wir eventuell einen Änderungskonflikt vorliegen. Aber auch nur dann, wenn die Änderungen and den einzelnen Feldern unterschiedlich sind. Welche Änderung denn hier nun die richtig ist, können nur die Mitarbeiter selbst bestimmen. Hier sollte bei den die Änderung betreffenden Mitarbeitern ein Dialog erscheinen, der auf den Konflikt aufmerksam macht und sie auffordern, zu entscheiden, welche Version denn nun die Richtige ist. Mit diesem Verfahren wirst Du bei interaktiven Änderungen (also Änderungen, die am Bildschirm von Menschen vorgenommen werden), i.A. nur sehr selten auf Konflikte treffen. Und wenn, dann sind dies zum Einen auch Probleme in der Unternehmensdisziplin, und zum Anderen schnell lösbar. |
Re: Gleichzeitige Änderung des Datensatzes am anderen PC
Du könntest auch prüfen, welche Felder dieses Datensatzes geändert wurden. Und dann speicherst Du nur diese Felder.
Falls dann doch mehrere Felder von mehreren Usern gleichzeitig geändert wurden, muss Du auf Mechanismen meiner Vorredner zurück greifen. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 17:29 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-2025 by Thomas Breitkreuz