Datensatzsperre bei Mehrfach User Nutzung

[A.DA]

Hallo Zusammen,

ich möchte Datensätze vor einer Mehrfachbearbeitung schützen, dass wenn Benutzer 1 bearbeitet, Benutzer 2 nicht zugreifen kann.

dazu habe ich unter Datei->Optionen->Clienteinstellung -- Erweitert
Standard bei Datensatzsperrung

• Bearbeiteter Datensatz
• Datenbank mit Sperrung auf Datensatzebene öffnen

aktiviert.

Mein Problem nun, wenn eine Update Routine auslöse bekomme ich zwei Meldungen

1. es wird 1 Zeile aktualisiert.....
2. MS Access kann Datensatz nicht aktualisieren....... wg. Sperrverletzung

Wenn ich im Formular unter Daten die Sperrung deaktiviere funktioniert es...

Verstehe ich da was grundlegen falsch?

Damit erreiche ich doch, wenn Benutzer 1 den Datensatz X öffnet und Benutzer 2 ihn in der Zeit auch bearbeiten möchte, dass Benutzer 2 zwar lesen aber nicht bearbeiten kann.....

das heiß aber nicht dass Benutzer 1 auch nicht bearbeiten kann...

[defo]

Ich kenne die Schalter und das von MS geplante Verhalten dafür nicht. Im Grunde wäre schon fraglich, ob die Sperrung auf Datensatzebene eine Schreibsperre ist.

Dann gibt es ohne weiteres die Möglichkeit, dass du selbst durch verschiedene (offene) Formulare, Abfragen oder auch VBA Code / Macros unbeabsichtigt diesen Datensatz sperrst.
Mir ist auch nicht mehr geläufig, ob es in Access sowas wie "Autoedit" gibt, also der automatische Wechsel in den Editmodus (des Datensatzes) bei "Betreten" im Grid. Das würde die Problematik verschärfen.

Businesslogik: Du solltest auch überlegen, ob und wie dieser Schritt (Sperre) genau erfolgen muss. Editierkonflikte entstehen nur, wenn 2xLeute das gleiche bearbeiten. Solche Arbeitsabläufe sind nicht selbstverständlich. Wenn sie tatsächlich auftreten, ist es u.U. zu kurz gedacht, dies mit den Datensatzsperren "abfangen" zu können.

[A.DA]

Ich habe im Netz diesen Link dazu gefunden..... und mich daran orientiert. Der Effekt ist schon der gewünscht, aber ich selbst kann auch nichts bearbeiten...

http://www.access-basics.de/index.ph...erbetrieb.html

[defo]

Ich habe nicht vor, im Netz etwas über ACCESS nachzulesen, für mich ist das Zeitverschwendung.
Was ist mit meinen Anmerkungen zu Deinen Formularen und Deinem Code?

[A.DA]

Dann gibt es ohne weiteres die Möglichkeit, dass du selbst durch verschiedene (offene) Formulare, Abfragen oder auch VBA Code / Macros unbeabsichtigt diesen Datensatz sperrst.

Ich habe zwar mehrere Tabellen, aber nur ein Formular bisher... Auch gibt es kein " Autoedit" in dem Formular... realisiere es so:

Private Sub cmdSpeichern_Click()
'bestehende Dienstbezeichnungen überarbeiten
Dim obj As Object
Dim strSQL, sql_auto_str As String


            For Each obj In Me.Controls

             ' Debug.Print "Type: " & obj.ControlType & " Name: " & obj.Name
            'Texteingabefenster werden geprüft
              If obj.ControlType = "109" Or obj.ControlType = "111" Then
              If obj.Name <> "personalID" And obj.Name <> "FilterBedienstete_Kombi" Then
                   sql_auto_str = sql_auto_str & obj.Name & " = '" & obj.Value & "', "
             End If
            '    If IsNull(obj.Value) Then
            '      MsgBox "Es wurden nicht die erforderlichen Angaben gemacht.", vbInformation
            '        Exit Sub
            '    End If
              End If
            Next obj
'Das letzte Leerzeichen und  Komma entfernen

    sql_auto_str = Left(sql_auto_str, Len(sql_auto_str) - 2)

'Debug.Print sql_auto_str
'DoCmd.SetWarnings False

     strSQL = "Update personalStamm Set " & sql_auto_str & _
              " WHERE personalID = " & Me.personalID.Value
Debug.Print strSQL


DoCmd.RunSQL strSQL
'MsgBox "Ein Datensatz wurde erfolgreich überarbeitet.", vbInformation
'Datenbank Warnung einschalten
'DoCmd.SetWarnings True
 End Sub

Habe es in PHP so realisiert, dass ich die ID bei Bearbeitung in eine eigene Tabelle eingetragen habe und nach Abschluss der Bearbeitung wurde sie wieder ausgetragen.

Nur hatte ich den Artikel gelesen und bin daher auf die Möglichkeit der Datensatzsperre gestoßen.

Normalerweise sollte es nicht notwendig sein, da die Aufgaben klar verteilt sind. Aber wie gesagt normalerweise....

[defo]

Wie gesagt, lange her. Aber in Access hast Du doch Objektzugriff auf die Formulardaten und da würde ich erstmal nicht mit einem eigenständigen Update arbeiten.
Das Edit der Daten geschieht also zuerst vollkommen unabhängig von expliziten SQL Statements. Mit einem normalen Formular editierst Du einfach Daten und speicherst, ohne eine Zeile Code.
Wie sieht das bei Dir aus?

[A.DA]

ich habe zuerst 2 Kombinationsfelder im Formular.

1. Kombi wird der Status ausgewählt... z. B aktiv oder Elternzeit oder.....
2. Kombi mit Auswahl der gefundenen Personen
3. Ausgabe der Daten im Formularbereich
4. Änderungen in den einzelnen Controls werden nicht sofort in der DB geändert
5. Änderungen nur mit der zuvor geposteten Routine...

Die Routine liest alle möglichen Eingabefelder des Formulars aus. Da ich die Eingabefelder wie die Spalten in der Datentabelle benenne kann ich mit wenig Aufwand die SQL Anweisung generieren...

[A.DA]

ich habe gerade mal

DoCmd.SetWarnings False

eingefügt....

Die Updateroutine läuft durch und trägt auch die geänderten Werte ein.... lasse ich die Meldung zu, bricht sie ab....

[defo]

Wie gesagt, wenn Du auf einem normalen Formular unterwegs bist, ohne Programmcode, sollte insert, update, delete möglich sein. Ein Sperrwarnung wäre dann eher ungewöhnlich (Im Einmannbetrieb).
Setzt Du per Code eine Updateanweisung "daneben", hast Du Dich selbst in die Sperrsituation gebracht. Dein Formular und Dein Code brauchen die Sperre.
Und nach meinem Verständnis ist eins von beidem überflüssig. Entweder Du überlässt das Update dem Formular und wirfst diesen Code weg oder Du behälst ihn und musst Deinem Formular beibringen, dass das Update anderweitig erfolgte.

[A.DA]

ich versuche mich nochmal...

[defo]

Du solltest auch überlegen, ob Dein Code zur Prüfung / Erstellung des Updatestatements sinnvoll ist.
Die Abfrage von Controltypes scheint mir nicht geeignet bzw. führt zu Fehlern, wenn das Formualr geändert wird. Wieso arbeitest Du nicht mit den echten Feldnamen (dataset/recordset)?

[A.DA]

ich lese mit den Controltypes doch nur die Controls ein, die Eingabefelder darstellen. Der Gedanke war, ein variables Updatestatement zu schreiben ohne immer wieder alle 30 Feldnamen zu notieren.

dadurch das ich den Bereich einschränke 109 Textfelder 111 Kombifelder dürfte ein Fehler eher ausbleiben.

Ich habe es jetzt nochmal mit dem direkten Objektzugriff probiert... funktioniert.

ich hatte im Formular den Datensatzmarkierer aus, so wie ich finde, optischen Gründen ausgeschaltet.
Wenn ich ihn anzeigen lasse und mich im "Bearbeiten" befinde und nun jemand den gleichen Datensatz öffnet kann er ihn lesen. Möchte er den Datensatz bearbeiten, ist es nicht möglich und im Datensatzmarkierer steht ein durchgestrichener Kreis.
verlasse ich den Datensatz erscheint dort wieder dieser kleine Pfeil und die geänderten Daten sind jetzt im Formular sichtbar.

Ich denke das Problem, das keines war, ist gelöst!!!

Danke für den Denkanstoß!! Ich bin Neuling in Access und denke vermutlich noch nicht in Access

[defo]

Danke für den Denkanstoß!! Ich bin Neuling in Access und denke vermutlich noch nicht in Access

Da ist nicht so viel Access spezifisches. Wenn Du von PHP kommst, ist es natürlich anders. Aber das sind grundsätzliche Unterschiede, die zwischen stateless Web Anwendungen und (fat)Client /Server Anwendungen (statefull) bestehen.

Ein Fatclient (hier Access) hat erstmal (mindestens) einen geöffneten Cursor zu den selektierten Daten. Dazu ein Object, glaub recordset oder so bei Access, unter dem Direktzugriff auf den (jeweils aktuellen) Datensatz vorliegt, inkl. den Methoden zum Posten, Löschen usw.