Autor Beitrag
Klaus Müller
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 58
Erhaltene Danke: 1

W2000,XP,W2k2S,W2k3S,S2k7S
Delphi XP
BeitragVerfasst: Di 20.11.12 11:55 
Da ich viel mit Access Datenbanken Programire, gibt es natürlich auch die Frage wie löse ich die Datensatzsperrung im Mehrbenutzer Betrieb. Grundsätzlich hat Access selber hierzu ja 2. Möglichkeiten. Ich kann in einem Formular einstellen ob die ganze Tabelle gesperrt wird, oder ob nur der bearbeitende Datensatz gesperrt wird. Nur wie realisier ich das in Delphi?
Ein Idee habe ich schon, beim Umschalten in den Edit Mode kann man den Datensatz Status abfragen. Wenn der Datensatz schon im Edit Modus ist kann man die Umschaltung sperren. Das Funktioniert aber leider nur wenn alle Formulare auf der selben Abfrage sind, nur leider besteht einen Applikation oft aus mehreren Abfragen, die dann natürlich ihre Daten im Endeffekt aus der gleichen Tabelle holen nur ist die Dataset Eigenschaft einer Abfrage die gleiche wie die der darunter liegenden Tabelle?
Was schlagt ihr für Lösungen vor?
Tranx
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starofftopic star
Beiträge: 648
Erhaltene Danke: 85

WIN 2000, WIN XP
D5 Prof
BeitragVerfasst: Di 20.11.12 13:25 
Es gibt eine Möglichkeit, die allerdings voraussetzt, dass die verschiedenen Abfragen auch wenigstens in einem Feld gleich sind. Du definierst eine Tabelle: Nutzung, mit zwei Feldern: Nutzer und Abfrage. Es wird dann beim Öffnen der Abfrage ein Datensatz in die Tabelle eingetragen, mit dem Namen des Nutzers und der Abfrage/Tabelle. Da kann man auch vor dem Öffnen abfragen, ob dieses Abfrage/Tabelle schon in Benutzung ist. Wird die Abfrage beendet, wird der eigene Eintrag dann wieder in der "Nutzungstabelle" gelöscht. Das kannst Du auch für einzelne Datensätze machen. Dann in der zugehörigen Tabelle ein Feld "Nutzer" einrichten.

Bei jeder Nutzung wird zuerst die Abfrage gemacht, ob die Nutzung möglich ist, wenn ja, wird der Eintrag beim Feld "Nutzer" gemacht und dann kann man die Tabelle/den Datensatz editieren. Dann beim Beenden den eigenen Eintrag wieder löschen. Problem ist nur, wenn z.B. das Programm hängen bleibt und über den Taskmanager beendet werden muss. Dann wird der Eitnrag nicht gelöscht. Da vieleicht auf Adminebene eine Abfrage starten, die alle Nutzereinträge löscht.

Zugegeben, das ist eine nicht wirklich sichere Methode. Vieleicht gibt es ja wesentlich Besseres. Bin mal gespannt.

_________________
Toleranz ist eine Grundvoraussetzung für das Leben.
Klaus Müller Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 58
Erhaltene Danke: 1

W2000,XP,W2k2S,W2k3S,S2k7S
Delphi XP
BeitragVerfasst: Mi 28.11.12 09:28 
Hallo Günter,

Danke für die Idee. Ich habe inzwischen auch noch mal gegoogled und folgendes gefunden, leider weiß ich nicht wo und von wem, die die ist aber gut :
Verwende statt eines Flagfeldes (True/False) einfach ein Feld
TStamp(DateTime).
Es gilt die Regel, ein Datensatz, dessen Feld TStamp einen Wert enthält, der
in der Zukunft liegt, darf von anderen Benutzern nicht verändert werden.
Vor dem Beginn der Bearbeitung eines Datensatzes prüft der jeweilige Client,
ob das Feld TStamp einen in der Zukunft liegenden Eintrag enthält.
Wenn ja, darf der Datensatz nicht verändert werden, weil er gerade von einem
anderen Benutzer bearbeitet wird.

Wenn nein, setzt der jeweilige Client dieses Feld auf Serverzeit + 5 Minuten
und beginnt dann mit der Bearbeitung des Datensatzes.

Hat der Client seine Bearbeitung abgeschlossen, speichert er die
neuen/geänderten Daten und setzt dabei auch das Feld TStamp wieder auf
DBNull.Value. Damit gilt der Datensatz wieder als frei zugänglich für alle
Benutzer.
Schafft es der Bearbeiter innerhalb der 5 Minuten nicht, seine Eingaben
abzuschliessen, kann man entweder seine Eingaben verwerfen und den
Eingabemodus beenden oder einfach kurz vor Ablauf der 5 Minuten den Eintrag
im Feld TStamp um weitere 5 Minuten verlängern.

Sollte der bearbeitende Client aus irgendeinem Grunde abstürzen, kann er
zwar das Feld TStamp nicht mehr löschen, was aber kein wirkliches Problem
ist, denn spätestens nach Ablauf der 5 Minuten liegt der Zeiteintrag nicht
mehr in der Zukunft und somit gilt für alle anderen Clients, dass der
Datensatz nicht mehr gesperrt ist.
Klaus Müller Threadstarter
ontopic starontopic starontopic starontopic starontopic starontopic starontopic starontopic star
Beiträge: 58
Erhaltene Danke: 1

W2000,XP,W2k2S,W2k3S,S2k7S
Delphi XP
BeitragVerfasst: Mi 28.11.12 09:44 
ADO Funktionen
Grundsätzlich gehen aber beide Methoden einen eigen weg.
Über CustTable.State kann man den aktuellen Status abfragen es gibt:
Values for the dataset State property:

dsInactive, Inactive
DataSet closed. Its data is unavailable.

dsBrowse, Browse
DataSet open. Its data can be viewed, but not changed. This is the default state of an open dataset.

dsEdit Edit
DataSet open. The current row can be modified.

dsInsert, Insert
DataSet open. A new row is inserted or appended.

dsSetKey, SetKey
TTable and TClientDataSet only. DataSet open. Enables setting of ranges and key values used for ranges and GotoKey operations.

dsCalcFields, CalcFields
DataSet open. Indicates that an OnCalcFields event is under way. Prevents changes to fields that are not calculated.

dsCurValue, CurValue
Internal use only.

dsNewValue, NewValue
Internal use only.

dsOldValue, OldValue
Internal use only.

dsFilter, Filter
DataSet open. Indicates that a filter operation is under way. A restricted set of data can be viewed, and no data can be changed.

Wenn man also in der Eigenschaft (Bevor Edit) der Tabelle oder Abfrage
Die Eigenschaft abfragt kann man ein Umschalten verhindern.
Soweit die Theorie, wenn ich es Programmier habe kann ich hier noch nachreichen.