Wenn zwei dieselbe Zeile anfassen

Du kennst das.
Zwei Leute öffnen denselben Auftrag.
Beide ändern etwas.
Einer speichert – der andere kriegt’s nicht mit.
Daten überschrieben, Konflikt vorprogrammiert.

Standardverhalten in Access oder auch bei SQL-Backends.
Aber: Du kannst mehr Kontrolle reinbringen.

Arten von Sperrung

Sperrung	Verhalten
Optimistisch	Zugriff für alle, Konflikt beim Speichern
Pessimistisch	Nur einer darf bearbeiten
Logisch selbstgebaut	Nutzer blockiert gezielt über eigenes Feld

Access nutzt standardmäßig optimistische Sperrung.
Das reicht oft – aber nicht immer.

Option 1: Access-eigene pessimistische Sperrung

Im Formular unter „Daten“ → „Sperren“
Wähle: „Bearbeiteter Datensatz“

Dann wird der aktuelle Datensatz für andere gesperrt.
Aber: Funktioniert nur bei Access-Backend.
Und nicht immer stabil im Netzwerkbetrieb.

Tipp: Funktioniert besser bei .accdb als bei .mdb.

Option 2: Sperrung per Logik (empfohlen)

Du baust Dir eine eigene Sperre.
Einfaches Prinzip: In der Tabelle steht, wer gerade dran ist.

Struktur

In der Tabelle tblAuftrag:

• Feld BearbeitetVon (Text)
• Feld GesperrtSeit (Datum/Uhrzeit)

Beim Öffnen:

Function SperreDatensatz(AuftragsNr As Long) As Boolean

    Dim rs As DAO.Recordset
    Set rs = CurrentDb.OpenRecordset("SELECT * FROM tblAuftrag WHERE AuftragsNr = " & AuftragsNr, dbOpenDynaset)

    If Not IsNull(rs!BearbeitetVon) Then
        MsgBox "Dieser Auftrag wird gerade von " & rs!BearbeitetVon & " bearbeitet.", vbExclamation
        SperreDatensatz = False
    Else
        rs.Edit
        rs!BearbeitetVon = Environ("USERNAME")
        rs!GesperrtSeit = Now
        rs.Update
        SperreDatensatz = True
    End If

    rs.Close
    Set rs = Nothing

End Function

Beim Schließen:

Function EntsperreDatensatz(AuftragsNr As Long)

    CurrentDb.Execute _
        "UPDATE tblAuftrag SET BearbeitetVon = Null, GesperrtSeit = Null WHERE AuftragsNr = " & AuftragsNr

End Function

Vorteil:

• Funktioniert unabhängig vom Backend
• Nutzer wissen, wer wo dran ist
• Du kannst Zeitüberschreitungen einbauen

Beispiel:

Wenn GesperrtSeit älter als 30 Minuten → automatische Entsperrung.

Option 3: Sperrung in SQL Server mit Lock-Tabelle

Wenn Du mit SQL Server arbeitest, kannst Du das Ganze dort regeln.

T-SQL-Tabelle:

CREATE TABLE dbo.Sperren (
    ObjektTyp VARCHAR(50),
    ObjektID INT,
    GesperrtVon NVARCHAR(100),
    GesperrtSeit DATETIME DEFAULT GETDATE()
)

Beim Öffnen:

IF EXISTS (
    SELECT 1 FROM dbo.Sperren WHERE ObjektTyp = 'Auftrag' AND ObjektID = 123
)
    RAISERROR ('Datensatz bereits gesperrt.', 16, 1)
ELSE
    INSERT INTO dbo.Sperren (ObjektTyp, ObjektID, GesperrtVon)
    VALUES ('Auftrag', 123, SYSTEM_USER)

Beim Schließen:

DELETE FROM dbo.Sperren WHERE ObjektTyp = 'Auftrag' AND ObjektID = 123

So hast Du Sperren zentral verwaltet – und kannst sie sogar über ein Admin-Tool aufheben.

Sonderfall: Nur Anzeige statt Bearbeitung

Wenn Du erkennst, dass ein Datensatz gesperrt ist, kannst Du das Formular schreibgeschützt öffnen:

DoCmd.OpenForm "frmAuftrag", , , "AuftragsNr = 123", acFormReadOnly

So bleibt der Nutzer handlungsfähig – aber ändert nichts.

Mein Fazit

Zugriffsprobleme bei Mehrbenutzer-Systemen sind vermeidbar.
Access und SQL Server geben Dir Werkzeuge an die Hand – aber Du musst sie nutzen.

Wenn Du willst, baue ich Dir ein Sperrsystem, das funktioniert, protokolliert und niemanden blockiert.
Nicht hübsch – aber norddeutsch sauber.