{"id":55000499,"date":"2026-02-01T00:00:00","date_gmt":"2026-03-10T11:58:24","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=499"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"SQL_ServerMigration_Anpassen_des_VBACodes","status":"publish","type":"post","link":"https:\/\/vbentwickler.de\/SQL_ServerMigration_Anpassen_des_VBACodes\/","title":{"rendered":"SQL Server-Migration: Anpassen des VBA-Codes"},"content":{"rendered":"

Wenn Du Deine Datenbank zum SQL Server migriert hast, also alle Tabellen in einer SQL Server-Datenbank liegen und mit dem Frontend verknüpft sind, kannst Du ohne Probleme über die Tabellenverknüpfungen auf die Tabellen im SQL Server zugreifen. Wenn Du jedoch per VBA, speziell mit den Methoden OpenRecordset und Execute, auf diese Tabellen zugreifen möchtest, kann es zu Fehlermeldungen kommen. In diesem Artikel erläutern wir, welche Fehler dies sind, warum sie auftreten und wie Du Deine Datenzugriffe auf die Tabellen der SQL Server-Datenbank so anpasst, dass sie fehlerfrei laufen. Außerdem schauen wir uns eine Besonderheit an, die beim Anlegen neuer Datensätze mit der AddNew-Methode des Recordset-Objekts auftritt – und schließlich gibt es noch eine Besonderheit bei Formularen, die wir ebenfalls berücksichtigen.<\/b><\/p>\n

Wenn Du die Migration zum SQL Server zum Beispiel mit dem SQL Server Migration Assistant durchgeführt hast, steht als nächster Schritt in der Regel der Test an, wie sich das Access-Frontend mit den Tabellen aus dem neuen SQL Server-Backend verträgt.<\/p>\n

Dabei schauen wir uns in diesem Artikel primär die VBA-Seite an. Hier treten verschiedene Fehler auf, die wir uns zunächst einmal ansehen.<\/p>\n

Fehler beim Öffnen eines Recordsets<\/h2>\n

Der erste Fehler, der auftreten kann und vermutlich auch auftreten wird, wenn Du die OpenRecordset<\/b>-Methode des Database<\/b>-Objekts verwendest, ist der aus Bild 1.<\/p>\n

\"Fehler<\/p>\n

Bild 1: Fehler in der OpenRecordset-Methode<\/span><\/b><\/p>\n

Die Fehlermeldung ist aussagekräftig genug, um den Fehler selbst zu beheben: Wir benötigen einen weiteren Parameter namens dbSeeChanges<\/b>.<\/p>\n

Diesen fügen wir wie folgt zur OpenRecordset<\/b>-Methode hinzu:<\/p>\n

Set<\/span> rst = db.OpenRecordset(\"tblBuecher\", _\r\n    dbOpenDynaset, dbSeeChanges)<\/pre>\n
Diese Konstanten müssen wir immer als dritten Parameter angeben, wenn wir mit OpenRecordset <\/b>eine Tabelle oder Abfrage öffnen wollen.<\/p>\n
Wenn wir bisher wie in folgendem Beispiel überhaupt keinen Parameter angegeben haben, erscheint die gleiche Fehlermeldung:<\/p>\n
Set<\/span> rst = db.OpenRecordset(\"tblBuecher\")<\/pre>\n
Wir können dann aber nicht einfach dbSeeChanges<\/b> wie hier als dritten Parameter setzen und den zweiten Parameter leer lassen:<\/p>\n
Set<\/span> rst = db.OpenRecordset(\"tblBuecher\", , dbSeeChanges)<\/pre>\n
Dies würde bedeuten, dass beim OpenRecordset <\/b>der Standardwert für den zweiten Parameter verwendet wird, der dbOpenTable <\/b>lautet.<\/p>\n
Und dbOpenTable <\/b>funktioniert mit ODBC-Tabellenverknüpfungen gar nicht. Wir müssen also einen der übrigen Werte für den zweiten Parameter angeben.<\/p>\n
Wenn wir hingegen dbOpenSnapshot <\/b>oder dbOpenForwardOnly <\/b>nutzen, brauchen wir dbSeeChanges <\/b>nicht anzugeben. Diese beiden Methoden öffnen das Recordset nämlich schreibgeschützt.<\/p>\n
Dies liefert bereits einen wichtigen Hinweis auf den Grund für die Fehlermeldung. Wenn wir diese nur erhalten, wenn wir das Recordset in dem Modus öffnen, in dem wir es bearbeiten können, muss es etwas mit dem Bearbeiten zu tun haben.<\/p>\n
Außerdem tritt dieser Fehler nur auf, wenn die zum SQL Server migrierte Tabelle ein Autowert-Feld als Primärschlüsselfeld enthält. Dieses wird im SQL Server bei der Migration als IDENTITY<\/b>-Spalte abgebildet, was im Grunde nichts anderes ist als ein Autowert.<\/p>\n
Der entscheidende Unterschied ist jedoch, dass die Identitätsspalte nun vom SQL Server gefüllt und verwaltet wird und nicht mehr direkt von der Access-Datenbank aus.<\/p>\n
Nun stellen wir uns vor, dass wir im Recordset mit AddNew <\/b>einen neuen Datensatz anlegen. Dies sorgt dafür, dass beim Speichern zwar ein neuer Identitätswert in der SQL Server-Tabelle angelegt wird, aber dieser wird nicht automatisch an Access zurückgegeben.<\/p>\n
Um genau dies zu gewährleisten, muss man den Parameter dbSeeChanges <\/b>setzen. Er sorgt dafür, dass bei Anlegen neuer Datensätze das Recordset direkt aktualisiert wird und SQL Server die ID des neuen Datensatzes an Access zurückmeldet.<\/p>\n
Zusammengefasst: dbSeeChanges <\/b>zwingt DAO\/ODBC dazu, nach einem Insert<\/b>\/Update <\/b>die serverseitig erzeugten beziehungsweise geänderten Werte (zum Beispiel IDENTITY<\/b>) wieder einzulesen. Ohne dieses Flag bricht DAO bei schreibenden Zugriffen auf verknüpfte SQL-Server-Tabellen mit Fehler 3622 <\/b>ab.<\/p>\n
OpenRecordset für ein QueryDef-Objekt<\/h2>\n
Das Gleiche gilt, wenn wir OpenRecordset <\/b>als Methode eines QueryDef<\/b>-Objekts ausführen. Im folgenden Beispiel erstellen wir ein QueryDef<\/b>-Objekt auf Basis einer Abfrage.<\/p>\n
Wenn wir ein Recordset für dieses QueryDef<\/b>-Objekt öffnen wollen, müssen wir ebenfalls dbSeeChanges übergeben – dieses Mal allerdings mit dem zweiten Parameter:<\/p>\n
Public Sub <\/span>Test_Recordset_1()\r\n    Dim <\/span>db As <\/span>DAO.Database\r\n    Dim <\/span>qdf As <\/span>DAO.QueryDef\r\n    Dim <\/span>rst As <\/span>DAO.Recordset\r\n    Set<\/span> db = CurrentDb\r\n    Set<\/span> qdf = db.CreateQueryDef(\"\", _\r\n        \"SELECT * FROM tblBuecher\")\r\n    Set<\/span> rst = qdf.OpenRecordset(dbOpenDynaset, _\r\n        dbSeeChanges)\r\n    Do While<\/span> Not<\/span> rst.EOF\r\n        Debug.Print<\/span> rst!Buchtitel\r\n        rst.MoveNext<\/span>\r\n    Loop<\/span>\r\nEnd Sub<\/span><\/pre>\n
Fehler beim Ausführen von Aktionsabfragen<\/h2>\n
Aktionsabfragen wie INSERT INTO<\/b>, UPDATE <\/b>oder DELETE <\/b>können wir auf zwei Arten ausführen:<\/p>\n
    \n
  • Docmd.RunSQL<\/b><\/li>\n
  • Execute<\/b>-Methode des Database<\/b>-Objekts<\/li>\n<\/ul>\n
    Aktionsabfragen mit DoCmd.RunSQL<\/h2>\n
    Wenn wir die DoCmd.RunSQL<\/b>-Methode verwenden, können jede der folgenden Aktionsabfragen ohne Fehler ausführen:<\/p>\n
    DoCmd.RunSQL \"INSERT INTO tblBuecher(BuchID, Buchtitel) VALUES(38, ''Buch'')\"\r\nDoCmd.RunSQL \"UPDATE tblBuecher SET Buchtitel = ''Buch 1'' WHERE BuchID = 38\"\r\nDoCmd.RunSQL \"DELETE FROM tblBuecher WHERE BuchID = 38\"<\/pre>\n
    Aktionsabfragen mit Execute<\/h2>\n
    Bei Verwendung der Execute<\/b>-Methode sieht dies anders aus. Allein das Anlegen eines Datensatzes wie folgt gelingt ohne Fehlermeldung:<\/p>\n
    Public Sub <\/span>Test_DbExecute_INSERTINTO()\r\n    Dim <\/span>db As <\/span>DAO.Database\r\n    Set<\/span> db = CurrentDb\r\n    db.Execute \"INSERT INTO tblBuecher(BuchID, Buchtitel) \" _\r\n        & \"VALUES(37, ''Buch'')\", dbFailOnError\r\nEnd Sub<\/span><\/pre>\n
    Wenn wir jedoch versuchen, diesen Datensatz zu aktualisieren, erhalten wir wieder den Fehler mit der Nummer 3622<\/b>:<\/p>\n
    Public Sub <\/span>Test_DbExecute_UPDATE()\r\n    Dim <\/span>db As <\/span>DAO.Database\r\n    Set<\/span> db = CurrentDb\r\n    db.Execute \"UPDATE tblBuecher SET Buchtitel = ''Buch'' \" _\r\n        & \"WHERE BuchID = 36\", dbFailOnError\r\nEnd Sub<\/span><\/pre>\n
    Und auch beim Löschen eines Datensatzes tritt dieser Fehler auf:<\/p>\n
    Public Sub <\/span>Test_DbExecute_DELETE()\r\n    Dim <\/span>db As <\/span>DAO.Database\r\n    Set<\/span> db = CurrentDb\r\n    db.Execute \"DELETE FROM tblBuecher WHERE BuchID = 36\",  _\r\n        dbFailOnError\r\nEnd Sub<\/span><\/pre>\n
    Diesen können wir ähnlich beheben wie bei der OpenRecordset-Methode. Dieses Mal müssen wir dbSeeChanges <\/b>jedoch nicht als weiteren Parameter anhängen, sondern wir müssen diesen mit dem vorhandenen (und immer dringend empfohlenen) dbFailOnError <\/b>in einem Parameter vereinen. Das gelingt über den Plus-Operator (+<\/b>) etwa wie folgt:<\/p>\n
    db.Execute \"UPDATE tblBuecher SET Buchtitel = ''Buch'' \" _\r\n    & \"WHERE BuchID = 36\", dbFailOnError + dbSeeChanges<\/pre>\n
    Warum aber funktioniert INSERT INTO <\/b>ohne die Angabe von dbSeeChanges<\/b>, UPDATE <\/b>und DELETE <\/b>nicht? Weil INSERT INTO <\/b>in diesem Fall direkt an den SQL Server durchgereicht wird. Für die anderen Abfragen sind jedoch Änderungen an bestehenden Datensätzen nötig – und dafür müssen die Primärschlüssel wieder zwischen Access und dem SQL Server synchron gehalten werden.<\/p>\n
    Probleme mit Ja\/Nein-Feldern<\/h2>\n
    Ein weiteres Problem, das dieses Mal eher inhaltliche Fehler produziert statt Laufzeitfehler, sind Ja\/Nein<\/b>-Felder. Wenn wir eine Tabelle mit Ja\/Nein<\/b>-Feldern zum SQL Server übertragen, wird daraus standardmäßig der Datentyp bit <\/b>erzeugt.<\/p>\n
    Hier gibt es zunächst einen wichtigen Unterschied zu berücksichtigen: Während in Access der Wert für Ja<\/b>\/True<\/b> intern als -1 <\/b>und der Wert für Nein<\/b>\/False <\/b>als 0 <\/b>gespeichert wird, kann das bit<\/b>-Feld lediglich die Werte 1 <\/b>und 0 <\/b>speichern.<\/p>\n
    Im SQL Server haben die Werte 1 <\/b>und 0 <\/b>auch keine tiefergehende Bedeutung – sie entsprechen lediglich den Zahlenwerten.<\/p>\n
    Dass Access die Werte dieser Felder korrekt als True <\/b>oder False <\/b>interpretiert, stellt der ODBC-Treiber sicher. Mit Tabellen, die per ODBC verknüpft sind, ändert sich auch erst einmal nichts: 1 <\/b>entspricht True <\/b>und 0 <\/b>entspricht False<\/b>.<\/p>\n
    Wenn wir also zum Beispiel in der Beispieldatenbank alle gelesenen Bücher abfragen wollen, funktioniert die folgende Abfrage auf der entsprechenden Tabellenverknüpfung korrekt:<\/p>\n
    SELECT * FROM tblBuecher WHERE Gelesen = True<\/span><\/pre>\n
    Auch False <\/b>funktioniert hier einwandfrei.<\/p>\n
    Gerade wenn wir solche Abfragen mit dem Abfrageentwurf zusammenstellen, ist sichergestellt, dass diese funktionieren, da dieser für Ja\/Nein<\/b>-Felder auch die Werte -1 <\/b>und 0 <\/b>immer in Wahr <\/b>und Falsch <\/b>übersetzt.<\/p>\n
    Nun schauen wir uns aber ein Recordset an, das wir per VBA öffnen. Hier verwenden wir nicht den Wert True <\/b>als Vergleichswert, sondern den Wert -1<\/b>:<\/p>\n
    Public Sub <\/span>Test_TrueFalse()\r\n    Dim <\/span>db As <\/span>DAO.Database\r\n    Dim <\/span>rst As <\/span>DAO.Recordset\r\n    Set<\/span> db = CurrentDb\r\n    Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM tblBuecher \" _\r\n        & \"WHERE Gelesen = -1\", dbOpenDynaset, dbSeeChanges)\r\n    Do While<\/span> Not<\/span> rst.EOF\r\n        Debug.Print<\/span> rst!BuchID, rst!Buchtitel\r\n        rst.MoveNext<\/span>\r\n    Loop<\/span>\r\nEnd Sub<\/span><\/pre>\n
    Führen wir diese Abfrage aus, erhalten wir überraschenderweise keine Daten im Direktbereich!<\/p>\n
    Auch eine DCount<\/b>-Funktion, mit der wir die Anzahl der gelesenen Bücher prüfen wollen, liefert den Wert 0 <\/b>im Direktbereich:<\/p>\n
    Public Sub <\/span>Test_TrueFalseDLookup()\r\n    Debug.Print<\/span> DCount(\"BuchID\", \"tblBuecher\", \"Gelesen = -1\")\r\nEnd Sub<\/span><\/pre>\n
    Damit scheint festzustehen: In Abfragen, in denen nicht durch den Abfrageentwurf der Wert -1 <\/b>durch den Wert Wahr<\/b>\/True <\/b>ersetzt wird, erhalten wir nicht die korrekten Ergebnisse, weil hier tatsächlich der Access-Wert -1<\/b> mit dem im SQL Server gespeicherten Wert 1 <\/b>verglichen wird – und das liefert keine Ergebnisse.<\/p>\n
    Korrekt wäre hier also für das Recordset:<\/p>\n
    Set<\/span> rst = db.OpenRecordset(\"SELECT * FROM tblBuecher \" _\r\n    & \"WHERE Gelesen = 1\", dbOpenDynaset, dbSeeChanges)<\/pre>\n
    Und in der DCount<\/b>-Anweisung müssten wir Folgendes schreiben, um das korrekte Ergebnis zu erhalten:<\/p>\n
    Debug.Print<\/span> DCount(\"BuchID\", \"tblBuecher\", \"Gelesen = 1\")<\/pre>\n
    Müssen wir nun in allen Abfragen -1 <\/b>durch 1 <\/b>ersetzen?<\/p>\n
    Dies würde tatsächlich funktionieren, aber nur, wenn wir ausschließlich mit SQL Server-Tabellen arbeiten würden.<\/p>\n
    Wenn wir später einmal, aus welchem Grund auch immer, noch einmal auf Access-Tabellen umstellen, liefern die Abfragen wieder falsche Werte, weil Access beim Vergleich eines Ja\/Nein<\/b>-Feldes mit dem Wert -1<\/b>\/True <\/b>mit dem Wert 1 <\/b>wieder falsche Ergebnisse liefern würde.<\/p>\n
    Damit liegt die Lösung auf der Hand: Wir müssen einfach immer True <\/b>oder False <\/b>als Kriterium für Ja\/Nein<\/b>-Felder verwenden, solange diese Abfragen sich auf per ODBC verknüpfte Tabellen aus einer SQL Server-Datenbank beziehen.<\/p>\n
    Vorsicht beim Wechsel zu ADODB<\/h2>\n
    Wenn wir jedoch im Code Zugriffe auf die SQL Server-Datenbank per ADODB einstreuen, müssen wir wiederum aufpassen: ADODB-Recordsets werden direkt vom SQL Server eingelesen.<\/p>\n
    Dann müssen wir uns endgültig von True <\/b>und False <\/b>verabschieden und die in SQL Server verwendeten Werte für bit<\/b>-Felder als Kriterien nutzen, nämlich 1 <\/b>für True <\/b>und 0 <\/b>für False<\/b>.<\/p>\n
    Ein Beispiel sieht wie folgt aus:<\/p>\n
    Public Sub <\/span>Test_ADODB()\r\n    Dim <\/span>cnn As <\/span>ADODB.Connection\r\n    Dim <\/span>strConnection As String<\/span>\r\n    Dim <\/span>rst As <\/span>ADODB.Recordset\r\n    Set<\/span> cnn = New<\/span> ADODB.Connection\r\n    strConnection = \"Provider=MSOLEDBSQL;\" _\r\n        & \"Server=amvDesktop2023;Database=FE_Test;\" _\r\n        & \"Trusted_Connection=Yes\"\r\n    cnn.ConnectionString = strConnection\r\n    cnn.Open\r\n    Set<\/span> rst = New<\/span> ADODB.Recordset\r\n    rst.Open \"SELECT * FROM tblBuecher WHERE Gelesen = 1\", cnn\r\n    Do While<\/span> Not<\/span> rst.EOF\r\n        Debug.Print<\/span> rst!BuchID, rst!Buchtitel\r\n        rst.MoveNext<\/span>\r\n    Loop<\/span>\r\nEnd Sub<\/span><\/pre>\n
    Wenn wir hier True <\/b>oder False <\/b>als Vergleichswert nutzen, erhalten wir den Fehler Ungültiger Spaltenname<\/b> – der SQL Server kann diesen Wert nicht korrekt interpretieren. Und das Problem lässt sich hier auch mit dem Wert -1 <\/b>für True <\/b>nicht lösen – SQL Server verlangt hier nach dem Wert 1<\/b>, wenn die Abfrage sinnvolle Ergebnisse liefern soll.<\/p>\n
    Unter ADODB und SQL Server gilt T-SQL-Syntax<\/h2>\n
    Grundsätzlich gilt für den Zugriff von Access aus mit ADODB auf eine SQL Server-Datenbank, dass wir hier nicht mehr mit Access-SQL arbeiten können, sondern mit T-SQL.<\/p>\n
    Das spiegelt sich zuerst in einer anderen Verwendung von Platzhaltern in Abfragen mit dem Vergleichsoperator LIKE <\/b>wider – statt des Sternchens für beliebig viele Zeichen nutzen wir hier das Prozentzeichen und statt des Fragezeichens für ein beliebiges Zeichen den Unterstrich.<\/p>\n
    Das Auflisten aller wichtigen Unterschiede zwischen Access-SQL und T-SQL würde an dieser Stelle allerdings den Rahmen sprengen.<\/p>\n
    Autowert-ID auslesen bei AddNew funktioniert nicht mehr<\/h2>\n
    Zurück zum Datenzugriff per DAO: Unter Access kommt es oft vor, dass wir per VBA einen neuen Datensatz nicht mit INSERT INTO <\/b>anlegen, sondern mit der AddNew<\/b>-Methode des Recordset<\/b>-Objekts. Anschließend tragen wir die Werte für die einzelnen Felder des neuen Datensatzes ein und speichern diesen mit der Methode Update<\/b>.<\/p>\n
    Wenn wir danach eine Aktion durchführen wollen, für die wir den Primärschlüsselwert des als Autowert deklarierten Access-Feldes benötigen – beispielsweise, um diesem Buch gleich einen Autor zuzuweisen -, greifen wir typischerweise auf das Primärschlüsselfeld des Recordsets zu und speichern diesen in einer entsprechenden Variablen.<\/p>\n
    Im folgenden Beispiel erstellen wir ein neues Buch in der Tabelle tblBuecher <\/b>und lesen den automatisch generierten Wert des Feldes BuchID <\/b>in die Variable lngBuchID <\/b>ein:<\/p>\n
    Public Sub <\/span>Test_Autowert()\r\n    Dim <\/span>db As <\/span>DAO.Database\r\n    Dim <\/span>rst As <\/span>DAO.Recordset\r\n    Dim <\/span>lngBuchID As Long<\/span>\r\n    Set<\/span> db = CurrentDb\r\n    Set<\/span> rst = db.OpenRecordset(\"tblBuecher\", _\r\n        dbOpenDynaset)\r\n    With<\/span> rst\r\n        .AddNew<\/span>\r\n        !Buchtitel = \"Neues Buch\"\r\n        lngBuchID = !BuchID\r\n        .Update\r\n    End With<\/span>\r\n    ''... etwas mit lngBuchID machen\r\nEnd Sub<\/span><\/pre>\n
    Wenn wir mit verknüpften SQL Server-Tabellen arbeiten, funktioniert dies nicht mehr. Statt des Wertes erhalten wir Fehler 94<\/b>, Unzulässige Verwendung von Null <\/b>(siehe Bild 2).<\/p>\n
    \"Fehler<\/p>\n
    Bild 2: Fehler beim Zugriff auf den Autowert eines neuen Datensatzes<\/span><\/b><\/p>\n
    Der Grund ist, dass der neue Primärschlüsselwert erst auf dem SQL Server erzeugt wird, wenn wir den Datensatz mit der Update<\/b>-Methode speichern. Wir können nun versuchen, den Wert nach dem Aufruf von Update <\/b>einzulesen:<\/p>\n
    ...\r\nSet<\/span> rst = db.OpenRecordset(\"tblBuecher\", dbOpenDynaset, _\r\n    dbSeeChanges)\r\nWith<\/span> rst\r\n    .AddNew<\/span>\r\n    !Buchtitel = \"Neues Buch\"\r\n    .Update\r\n    lngBuchID = !BuchID\r\nEnd With<\/span>\r\n''... etwas mit lngBuchID machen\r\nDebug.Print<\/span> \"Neuer Autowert: \" & lngBuchID\r\n...<\/pre>\n
    Dies liefert allerdings immer den Wert des Primärschlüsselfeldes des ersten Datensatzes im Recordset.<\/p>\n
    Das liegt daran, dass der zu bearbeitende Datensatz nach dem Aufrufen von Update verlassen und der Datensatzzeiger wieder auf den ersten Datensatz des Recordsets gesetzt wird.<\/p>\n
    Man könnte nun versuchen, zum Beispiel mit DMax(“BuchID”, “tblBuecher”) <\/b>den größten Wert für das Autowert-Feld zu ermitteln.<\/p>\n
    Das ist allerdings nicht zuverlässig, denn es kann sein, dass in der Zwischenzeit ein anderer Benutzer ebenfalls einen neuen Datensatz angelegt hat und wir dann den Primärschlüsselwert dieses Datensatzes erhalten und eine falsche Zuordnung durchführen.<\/p>\n
    Zum Glück gibt es eine andere in der Praxis funktionierende Methode. Dabei stellen wir die Bookmark-Eigenschaft des Recordsets mit rst.LastModified <\/b>auf den zuletzt bearbeiteten Datensatz ein.<\/p>\n
    Warum ist das zuverlässig? Weil rst.LastModified <\/b>sich immer auf die Datensätze in der aktuellen Session beschränkt. Danach können wir den Primärschlüsselwert des neuen Datensatzes wie gewohnt auslesen und weiterverarbeiten:<\/p>\n
    ...\r\nSet<\/span> rst = db.OpenRecordset(\"tblBuecher\", dbOpenDynaset, _\r\n    dbSeeChanges)\r\nWith<\/span> rst\r\n    .AddNew<\/span>\r\n    !Buchtitel = \"Neues Buch\"\r\n    .Update\r\n    .Bookmark = rst.LastModified\r\n    lngBuchID = !BuchID\r\nEnd With<\/span>\r\n''... etwas mit lngBuchID machen\r\nDebug.Print<\/span> \"Neuer Autowert: \" & lngBuchID\r\n...<\/pre>\n
    Autowert-ID steht in Formularen nicht sofort zur Verfügung<\/h2>\n
    Wir machen auch noch einen kleinen Ausflug in die Welt der Formulare.<\/p>\n
    Im Formular aus Bild 3 haben wir dem Formular die Tabelle tblBuecher <\/b>als Datensatzquelle zugewiesen und einige Felder dieser Tabelle zum Detailbereich hinzugefügt.<\/p>\n
    \"Formular<\/p>\n
    Bild 3: Formular direkt nach dem Hinzufügen eines neuen Datensatzes<\/span><\/b><\/p>\n
    Wenn wir nun einen neuen Datensatz hinzufügen, liefert das Formular zunächst das gewohnte Bild – das Autowert-Feld zeigt für das Primärschlüsselfeld den Wert (Neu) <\/b>an.<\/p>\n
    Beginnen wir die Bearbeitung, würden wir wie bei Verwendung reiner Access-Tabellen direkt die Anzeige des neu vergebenen Autowertes im Primärschlüsselfeld erwarten. Das ist jedoch nicht der Fall (siehe Bild 4).<\/p>\n
    \"Formular<\/p>\n
    Bild 4: Formular direkt nach dem Start der Bearbeitung<\/span><\/b><\/p>\n
    Der Grund ist der gleiche wie beim Anlegen eines neuen Datensatzes mit der AddNew<\/b>-Methode des Recordset<\/b>-Objekts: Der neue Primärschlüsselwert wird erst generiert, wenn der Datensatz gespeichert wird und SQL Server den automatisch generierten Wert zurückliefert.<\/p>\n
    Hier gibt es keine kleine, zuverlässig funktionierende Technik. Wir müssten den Datensatz nach Beginn der Bearbeitung speichern, zum Beispiel im Ereignis Bei Geändert des Formulars.<\/p>\n
    Dieses wird nach dem ersten Ändern eines Feldes ausgelöst, also auch nach dem Eintippen des ersten Zeichens in ein Textfeld, und ist gleichbedeutend mit dem Versetzen des Formulars in den Zustand “In Bearbeitung”, was an der Anzeige des Stift-Symbols im Datensatzmarkierer zu erkennen ist.<\/p>\n
    Wir könnten den Datensatz dann speichern, indem wir zum Beispiel Me.Dirty <\/b>auf False <\/b>einstellen. Dies führt aber zum Speichern des Datensatzes mit all seinen Folgen – zum Beispiel werden alle Restriktionen geprüft, etwa ob ein Feld einen Wert enthalten muss. Ist das nicht der Fall, kann der Datensatz nicht gespeichert werden und wir erhalten einen Fehler.<\/p>\n
    Fehlerbehandlung mit ODBC und SQL Server<\/h2>\n
    Ein wichtiger Punkt ist die Fehlerbehandlung. Wenn wir in VBA arbeiten, erhalten wir für jeden Laufzeitfehler genau eine Fehlernummer und eine Fehlermeldung.<\/p>\n
    Wenn wir zum Beispiel versuchen, einen Datensatz mit INSERT INTO <\/b>zur Tabelle tblBuecher <\/b>hinzuzufügen und dabei einen Primärschlüsselwert angeben, der bereits vorhanden ist, erhalten wir die wenig aussagekräftige Fehlermeldung aus Bild 5.<\/p>\n
    \"Fehlermeldung<\/p>\n
    Bild 5: Fehlermeldung beim Ausführen einer SQL-Aktionsabfrage über ODBC<\/span><\/b><\/p>\n
    Für Fehler beim Zugriff auf ODBC-verknüpfte Tabellen gibt es jedoch eine Besonderheit. Wir können auch mehr als eine Fehlermeldung zurückerhalten. Das Err-Objekt liefert dabei immer nur die allgemeine Fehlermeldung, wie in diesem Beispiel Fehler 3146 <\/b>mit der Meldung ODBC-Aufruf fehlgeschlagen<\/b>.<\/p>\n
    Es gibt jedoch in der Fehlerbehandlung unter VBA nicht nur das Err<\/b>-Objekt, das zwar die meisten Informationen zum aktuellsten Fehler liefert.<\/p>\n
    Wir finden, wenn wir den Objektkatalog durchstöbern, in den Bibliotheken DAO <\/b>und ADODB <\/b>jeweils eine Errors<\/b>-Auflistung und auch noch eine Error<\/b>-Klasse (siehe Bild 6).<\/p>\n
    \"Weitere<\/p>\n
    Bild 6: Weitere Fehler-Objekte im Objektkatalog<\/span><\/b><\/p>\n
    Diese können wir wie in Listing 1 nutzen, um alle Fehler in Zusammenhang mit einer DAO- oder ADODB-Anweisung auszulesen.<\/p>\n
    Public Sub <\/span>Test_Fehler()\r\n    Dim <\/span>db As <\/span>DAO.Database\r\n    Dim <\/span>objError As <\/span>Error\r\n    Set<\/span> db = CurrentDb\r\n    On Error GoTo<\/span> Fehler\r\n    db.Execute \"INSERT INTO tblBuecher(BuchID, Buchtitel) VALUES(1, ''Buch'')\", dbFailOnError\r\n    Exit Sub<\/span>\r\nFehler:\r\n    For Each objError In Errors\r\n        Debug.Print<\/span> objError.Number, objError.Description\r\n    Next<\/span> objError\r\nEnd Sub<\/span><\/pre>\n
    Listing 1: Auslesen von ODBC-Fehlern<\/span><\/b><\/p>\n
    Wenn wir nun beispielsweise versuchen, einen bereits vorhandenen Wert in das Primärschlüsselfeld BuchID <\/b>zu schreiben, erhalten wir die folgenden Fehlermeldungen:<\/p>\n