Fehler bei verknüpften ODBC-Tabellen in Recordsets

2/2025, 2025, Abfragetechnik und SQL

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 den nun statt der ursprünglichen Tabellen verwendeten Tabellenverknüpfungen arbeitet, sondern auch mit VBA – insbesondere mit DAO-Recordsets – auf diese Daten zugreift. 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 Tabellenverknüpfung zu oder ändern Datensätze mit der Execute-Methode auf Basis einer Tabellenverknüpfung, tritt häufig der Fehler 3622 auf (siehe Bild 1):

Fehlermeldung bei Verwendung einer Recordset-Anweisung

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
Nur für Abonnenten

Ab hier wird’s wirklich spannend – der Rest ist exklusiv für Abonnenten.

Mit dem Abo von Access im Unternehmen bekommst du den kompletten Artikel – inklusive vollständigem Code, Beispieldatenbank und Schritt-für-Schritt-Erklärung.

So sparst du dir stundenlanges Herumprobieren, vermeidest teure Fehler in deiner Access-Anwendung und kannst Lösungen direkt in deinem Unternehmen einsetzen, statt nur darüber zu lesen.

Teste Access im Unternehmen jetzt 4 Wochen lang kostenlos: Voller Zugriff auf alle Artikel, Downloads und Beispieldatenbanken. Kein Risiko – wenn es für dich nicht passt, kündigst du einfach innerhalb der ersten vier Wochen.

Bereits Abonnent? Hier einloggen

Kostenlos & unverbindlich

Oder hast Du eine konkrete Frage zu Deiner eigenen Access-Anwendung?

Vielleicht stellt Deine Anwendung Dich vor eine Herausforderung, zu der Du bisher keine Lösung findest. Schlechte Performance, kein ausreichender Zugriffsschutz, Du bist unsicher über Dein Datenmodell oder Dein Code liefert unerklärliche Fehler?

In unserem kostenlosen Access-Audit schaut sich André Minhorst persönlich gemeinsam mit Dir Deine Lösung per Zoom an – und zeigt Dir, wo Datenmodell, VBA-Code, Ergonomie und Sicherheit Optimierungspotenzial bieten.

Jetzt kostenloses Access-Audit anfordern →

Schreibe einen Kommentar