Wer eine Migration seiner Access-Datenbank zum SQL Server durchgeführt hat und dabei beispielsweise den SQL Server Migration Assistant genutzt hat, hofft vielleicht, damit schon am Ziel zu sein. Tatsächlich kann das in ganz wenigen Fällen so sein. Das ist aber nicht der Fall, wenn man nicht nur mit Abfragen, Formularen oder Berichten auf die statt der ursprünglichen Tabellen nun verwendeten Tabellenverküpfungen arbeitet, sondern außerdem per VBA auf diese Daten zugreift – insbesondere mit DAO-Recordsets. Dabei treten gelegentlich Fehler auf. Warum diese nur gelegentlich auftreten und wie wir diese Fehler endgültig verhindern, zeigen wir in diesem Beitrag.
Voraussetzungen
Um die nachfolgenden Techniken verwenden zu können, benötigen wir die folgenden Voraussetzungen:
- Wir verwenden eine oder mehrere Tabellen einer SQL Server-Datenbank als Quelle für Tabellenverknüpfungen in unserer Access-Datenbank.
- Wir greifen mit DAO-Anweisungen wie db.OpenRecordset oder db.Execute auf diese Tabellenverknüpfungen zu, wobei db ein Verweis auf das Database-Objekt der aktuellen Access-Datenbank ist.
Fehler 3622 bei Verwendung von OpenRecordset oder Execute
Greifen wir mit der OpenRecordset-Methode auf die Daten einer Tabellenverküpfung zu oder ändern Datensätze mit der Execute-Methode auf Basis einer Tabellenverknüpfung, kommt es oft zum Fehler 3622 (siehe Bild 1):
Bild 1: Fehlermeldung bei Verwendung einer Recordset-Anweisung
Wenn Sie auf eine SQL Server-Tabelle zugreifen, die eine IDENTITY-Spalte enthält, müssen Sie für die OpenRecordset-Methode die dbSeeChanges-Option verwenden.
Was bedeutet das im Detail?
Schauen wir uns die Meldung genau an:
- wir greifen auf eine SQL Server-Tabelle zu,
- diese hat eine IDENTITY-Spalte und
- wir müssen dafür offensichtlich eine Option namens dbSeeChanges verwenden.
Der Fehler tritt auf, wenn wir Folgendes durchführen:
- Wir rufen Daten mit OpenRecordset ab.
- Wir löschen einen Datensatz mit Execute „DELETE FROM …“
- Wir ändern einen Datensatz mit Execute „UPDATE …“
Schauen wir uns Beispiele im Detail an. All diese Anweisungen lösen den Fehler aus:
CurrentDb.OpenRecordset("SELECT * FROM tblAnreden WHERE AnredeID = 1").Fields(0)
CurrentDb.Execute "DELETE FROM tblAnreden WHERE AnredeID = 15", dbFailOnError
CurrentDb.Execute "UPDATE tblAnreden SET Anrede = ''Test'' WHERE AnredeID = 15", dbFailOnError
Bei dieser Anweisung hier tritt der Fehler nicht auf:
CurrentDb.Execute "INSERT INTO tblAnreden(Anrede) VALUES(''Etwas'')", dbFailOnError
Der Grund ist, dass wir die Autowert-Funktion von Access zum SQL Server in Form einer IDENTITY-Eigenschaft migriert haben.
Damit Access über Änderungen an den Datensätzen im SQL Server-Backend informiert ist, müssen wir hier eine zusätzliche Option namens dbSeeChanges setzen.
Das ist sowohl bei OpenRecordset als auch bei Execute nötig.
Bei Execute jedoch nur bei UPDATE– und DELETE-Anweisungen, beim INSERT INTO existiert ja noch kein Datensatz und somit auch kein IDENTITY-Wert, den man hier abgleichen müsste.
Lösung
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
den kompletten Artikel im PDF-Format mit Beispieldatenbank
diesen und alle anderen Artikel mit dem Jahresabo