· IT-Infrastruktur  · 3 min read

Access-Schreibkonflikt mit MariaDB, MySQL oder MSSQL beheben

Die Fehlermeldung "Dieser Datensatz wurde seit Beginn der Bearbeitung von einem anderen Benutzer geändert" tritt in Access-Frontends mit externem Backend häufiger auf als erwartet. Die Ursache liegt im Datentyp, die Lösung in einem TIMESTAMP-Feld.

Die Fehlermeldung "Dieser Datensatz wurde seit Beginn der Bearbeitung von einem anderen Benutzer geändert" tritt in Access-Frontends mit externem Backend häufiger auf als erwartet. Die Ursache liegt im Datentyp, die Lösung in einem TIMESTAMP-Feld.

Der Access-Schreibkonflikt mit MariaDB oder MySQL ist ein klassisches Migrationsproblem: Access meldet einen Schreibkonflikt, obwohl kein zweiter Nutzer aktiv ist. Die Ursache liegt nicht in der Anwendung, sondern in einem fehlenden TIMESTAMP-Feld auf Datenbankseite.

Die Ausgangslage

Eine Access-Datenbank wurde auf MariaDB, MySQL oder Microsoft SQL Server migriert. Access bleibt als Frontend, das Backend läuft auf dem externen Datenbankserver. Bei Änderungen an Datensätzen erscheint:

“Schreibkonflikt. Dieser Datensatz wurde seit Beginn der Bearbeitung von einem anderen Benutzer geändert.”

Das Kuriose: Der Fehler tritt auch dann auf, wenn kein zweiter Benutzer aktiv ist.

Ursache

Access nutzt die JET-Datenbank-Engine für den externen Datenbankzugriff. JET vergleicht beim Speichern feldweise den aktuellen Zustand eines Datensatzes mit dem Zustand zum Zeitpunkt des Öffnens. Bei der Migration von Access zu MySQL oder MariaDB werden Datentypen manchmal nicht exakt übertragen. Felder ohne eindeutigen Änderungszeitstempel führen dazu, dass JET glaubt, ein anderer Prozess habe den Datensatz verändert.

Lösung: TIMESTAMP-Feld hinzufügen

Ein Feld mit dem Datentyp TIMESTAMP gibt JET einen zuverlässigen Anker für den Vergleich. Der Wert wird automatisch bei jeder Änderung aktualisiert.

Schritt 1: Backup anlegen

Vor jeder Schemaänderung an der produktiven Datenbank ein Backup erstellen.

Schritt 2: TIMESTAMP-Feld per ALTER TABLE hinzufügen

ALTER TABLE `tabellenname`
ADD COLUMN `TimeStamp` TIMESTAMP NULL
  DEFAULT CURRENT_TIMESTAMP()
  ON UPDATE CURRENT_TIMESTAMP()
  AFTER `letztes_feld`;

letztes_feld durch den tatsächlichen Spaltennamen ersetzen, nach dem das neue Feld eingefügt werden soll.

Schritt 3: Verknüpfung in Access neu laden

  1. Access öffnen
  2. Externe Daten, Neue Datenquelle
  3. Aus anderen Quellen, ODBC-Datenbank
  4. “Erstellen Sie eine Verknüpfung zur Datenquelle” wählen
  5. Bestehende ODBC-Datenquelle auswählen
  6. Tabelle auswählen und verknüpfen
  7. Alte Verknüpfung in Access entfernen, neue umbenennen

Nach der Neuverknüpfung erkennt Access das TIMESTAMP-Feld automatisch und nutzt es für die Konflikterkennung. Der Schreibkonflikt-Fehler tritt nicht mehr auf.

Wichtig bei MSSQL

Bei Microsoft SQL Server erfüllt ein rowversion-Feld (früher timestamp) dieselbe Funktion. Access erkennt diesen Datentyp und verwendet ihn für den Datensatzvergleich.

ALTER TABLE tabellenname
ADD rowversion_col rowversion;

Häufige Fragen

Warum tritt der Fehler auch bei einem einzelnen Benutzer auf? JET vergleicht Feldinhalte beim Speichern mit dem Zustand beim Öffnen. Ohne Zeitstempel-Feld interpretiert JET minimale Datentyp-Unterschiede als externe Änderung. Das TIMESTAMP-Feld gibt JET einen eindeutigen Vergleichsankerpunkt.

Muss ich für jede Tabelle ein TIMESTAMP-Feld anlegen? Ja, für jede Tabelle, bei der Access den Schreibkonflikt meldet. Das ALTER TABLE Statement ist in Sekunden ausgeführt, danach muss nur die Verknüpfung in Access neu geladen werden.

Funktioniert das auch bei Access-Frontends mit ODBC-Pass-Through-Abfragen? Nein, der TIMESTAMP-Trick gilt nur für verknüpfte Tabellen. Pass-Through-Abfragen umgehen JET komplett und haben das Problem typischerweise nicht.

Techiota unterstützt bei der Migration von Access-Datenbanken auf externe Backends und bei der Fehleranalyse in bestehenden Hybridlösungen. Sprechen Sie uns an über techiota.de.

Back to Blog

Related Posts

View All Posts »