![\"Datenbank](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_001.png\")
<\/p>\nAccess bietet von Haus aus eine komfortable Datenbindung für Formulare: Man trägt eine Tabelle oder Abfrage als Datensatzquelle ein, bindet die Steuerelemente über ihren Steuerelementinhalt an Felder – und Access erledigt den Rest. Wer jedoch sicherstellen möchte, dass seine Tabellen nicht von außen ausgelesen werden können, darf keine Tabellen oder Tabellenverknüpfungen mehr im Frontend haben. Wir müssen uns also nach einer Alternative umsehen. Dazu entfernen wir alle kritischen Elemente aus dem Frontend und bauen die Formulare um. Aber wie greifen wir auf die Daten zu? Dazu nutzen wir die Recordset-Eigenschaft von Formularen und Steuerelementen. Diese können ein per VBA zusammengestelltes Recordset nutzen. In diesem ersten Teil zeigen wir, wie das mit einfachen Detailformularen und in der Datenblattansicht funktioniert. Danach bauen wir unser Wissen aus und beschäftigen uns mit Haupt- und Unterformularen und Steuerelementen wie dem Kombinations- und dem Listenfeld.<\/b><\/p>\nADODB statt DAO<\/h2>\n
Warum nutzen wir in diesem Artikel ADODB statt DAO? Weil es flexibler ist, gerade wenn wir die vorgestellten Techniken auch für den Zugriff auf SQL Server-Datenbanken nutzen wollen.<\/p>\n
Als Beispiel nutzen wir eine Frontend-Datenbank, die aktuell noch über Tabellenverknüpfungen auf die Tabellen eines Backends zugreift. Dieses ist wiederum per Kennwort geschützt.<\/p>\n
Das ist ein wichtiger Baustein im Hinblick auf die Sicherheit der Daten, denn wenn der Benutzer Zugriff auf das Backend hat, kann er dieses theoretisch auch einfach kopieren. In diesem Fall wären die geplanten Sicherheitsmaßnahmen im Frontend nutzlos.<\/p>\n
Unser Frontend enthält zu Beginn noch die Verknüpfungen zu den Tabellen im Backend, die wir mit dem Bordmitteln von Access hinzugefügt haben (siehe Bild 1).<\/p>\n
<\/p>\n
Bild 1: Datenbank mit Tabellenverknüpfungen<\/span><\/b><\/p>\n Wir können mit Early Binding oder Late Binding auf die Elemente der ADODB-Bibliothek zugreifen.<\/p>\n Zum Programmieren nutzen wir allerdings Early Binding, da wir so IntelliSense verwenden können. Dazu fügen wir dem VBA-Projekt einen entsprechenden Verweis hinzu (siehe Bild 2).<\/p>\n Bild 2: Verweis auf die ADODB-Bibliothek<\/span><\/b><\/p>\n Wir werden immer wieder den gleichen Code verwenden, um die Recordset-Eigenschaften von Formularen und Steuerelementen mit Daten zu füllen. Daher legen wir gleich ein paar Funktionen an, welche diese Aufgabe erledigen und rufen diese einfach vom Formular aus auf.<\/p>\n Das Modul mdlADODB<\/b> enthält alle Hilfsfunktionen, die wir für den Zugriff auf die Datenbank benötigen. Wir legen es einmalig an und verwenden es in allen Formularen der Anwendung. Die erste Konstante steuert, welches Backend verwendet wird:<\/p>\n Mit dem Wert 1 <\/b>nutzen wir CurrentProject.Connection<\/b> – also die Verbindung, die Access für das aktuelle Frontend ohnehin offen hält. Das ist sinnvoll, wenn Frontend und Backend dieselbe Datenbank sind oder wenn die Tabellen des Backends per Tabellenverknüpfung eingebunden sind. Mit dem Wert 2<\/b> öffnen wir eine eigene ADODB-Verbindung auf eine kennwortgeschützte Access-Backend-Datenbank. Mit dem Wert 3<\/b> verbinden wir uns mit einem SQL Server. Der Wechsel des Backends ist damit auf eine einzige Zeile reduziert.<\/p>\n Die Verbindungsstrings für die beiden echten Verbindungen stehen als Konstanten im Modul. Für das Access-Backend ergänzen wir den Provider-String später um den Dateipfad und das Kennwort:<\/p>\n Für das Access-Backend benötigen wir zusätzlich den Dateinamen der Backend-Datenbank sowie das Kennwort. Beides steht ebenfalls als Konstante im Modul. Den vollständigen Pfad ermitteln wir zur Laufzeit per GetDBPfad<\/b>, damit die Anwendung auch nach einem Verschieben von Frontend und Backend in einen anderen Ordner weiterhin funktioniert:<\/p>\n Nur der Dateiname steht fest im Code – der Ordner wird immer zur Laufzeit aus CurrentProject.Path<\/b> abgeleitet. Wer Backend und Frontend in getrennten Ordnern betreibt, trägt stattdessen einfach den vollständigen Pfad als Konstante ein.<\/p>\n CurrentProject.Path <\/b>kann auch durch einen festen Pfad ersetzt werden. Alternativ kann man die Funktion auch so umbauen, dass der Pfad beispielsweise aus der Registry eingelesen wird. Wenn dort kein Pfad gespeichert ist, könnte man diesen per Datei-Dialog abfragen.<\/p>\n Die Funktion GetConnection<\/b> ist der zentrale Baustein des Moduls. Sie gibt abhängig von cIntConnection<\/b> eine geöffnete ADODB.Connection<\/b> zurück.<\/p>\n Alle anderen Funktionen des Moduls – und alle Formulare der Anwendung – rufen ausschließlich diese eine Funktion auf, um eine Verbindung zu erhalten (siehe Listing 1).<\/p>\n Listing 1: Die Funktion GetConnection<\/span><\/b><\/p>\n Bei Case 1<\/b> verlassen wir die Funktion sofort per Exit Function<\/b>: CurrentProject.Connection<\/b> ist bereits offen und gehört Access – wir dürfen sie weder über cnn.Open<\/b> öffnen noch später schließen.<\/p>\n Bei den Werten 2 <\/b>und 3 <\/b>stellen wir zunächst den Verbindungsstring zusammen und öffnen am Ende gemeinsam eine neue Verbindung. Diese neue Verbindung müssen wir später auch wieder schließen – dazu gleich mehr.<\/p>\n Beim Access-Backend ergänzen wir den Provider-String um den Pfad aus GetDBPfad()<\/b> und, falls vorhanden, um das Kennwort.<\/p>\n Der Schlüssel für das Datenbankpasswort lautet Jet OLEDB:Database Password<\/b> – dieser Name stammt noch aus der Zeit des Jet-Datenbankmoduls und wird vom neueren ACE-Provider unverändert weiterverwendet.<\/p>\n Die zweite Hilfsfunktion GetRecordset<\/b> öffnet ein Recordset auf Basis eines SQL-Strings und gibt es zurück. Sie kapselt die immer gleichen Schritte – Verbindung holen, Recordset anlegen, Cursor konfigurieren, öffnen – so dass wir in den Formularen nur noch den SQL-String übergeben müssen (siehe Listing 2).<\/p>\n Listing 2: Die Funktion GetRecordset<\/span><\/b><\/p>\n Cursor- und Sperrtyp sind als optionale Parameter mit sinnvollen Standardwerten ausgelegt. adOpenStatic<\/b> liefert einen statischen Cursor, der alle Daten einmalig in den Arbeitsspeicher lädt. Das ist die Voraussetzung für adUseClient<\/b>, denn clientseitige Cursor unterstützen nur statische oder Forward-Only-Cursor. adLockOptimistic<\/b> sperrt den Datensatz erst beim Update<\/b>-Aufruf kurz, was Konflikte im Mehrbenutzerbetrieb minimiert.<\/p>\n Warum adUseClient<\/b> fest und nicht als Parameter? Weil wir das Recordset anschließend an die Recordset<\/b>-Eigenschaft eines Formulars binden wollen – und Access erwartet dafür zwingend einen clientseitigen Cursor. Wer ein Recordset nur lesend durchlaufen möchte, ohne es ans Formular zu binden, kann zwar auch einen serverseitigen Cursor verwenden, aber für den Zweck dieser Beitragsreihe ist adUseClient<\/b> die richtige Wahl.<\/p>\n Ein wichtiges Detail: cnn<\/b> ist hier eine lokale Variable. Bei adUseClient<\/b> ist das kein Problem – ADODB trennt das Recordset nach dem Öffnen intern von der Verbindung, sodass die Connection freigegeben werden kann, ohne das Recordset zu beeinträchtigen.<\/p>\n Das Recordset lebt danach eigenständig im Speicher. Bei einem serverseitigen Cursor wäre das anders: Dort muss die Verbindung so lange offen bleiben, wie das Recordset verwendet wird.<\/p>\n Bevor wir das Modul in Formularen einsetzen, prüfen wir mit einer einfachen Testprozedur, ob Verbindung und Recordset korrekt funktionieren. Test_GetRecordset <\/b>öffnet ein Recordset mit den ersten zehn Datensätzen der Tabelle tblKunden<\/b> und gibt KundeID<\/b> und Firma<\/b> im Direktbereich aus:<\/p>\n Wir stellen cIntConnection<\/b> auf den gewünschten Wert, drücken F5<\/b> im VBA-Editor und prüfen im Direktbereich, ob die Daten korrekt ausgegeben werden. Liefert die Prozedur Ergebnisse, sind Verbindungsstring, Pfad und Kennwort korrekt – wir können mit der Implementierung der Formulare beginnen. Voraussetzung ist, dass es eine entsprechende Backend-Datenbank oder SQL Server-Datenbank gibt.<\/p>\n Damit kommen wir zum eigentlich Kern – dem Füllen der Recordset-Eigenschaft eines Formulars mit dem Ergebnis der Funktion GetRecordset<\/b>.<\/p>\n Um dieses einfach erstellen zu können, ist es wichtig, dass die Tabellen noch in der Datenbank liegen oder entsprechende Tabellenverknüpfungen vorhanden sind. Auf diese Weise können wir das Formular schnell über die Eigenschaft Datensatzquelle <\/b>mit der Tabelle verknüpfen und die Steuerelemente als gebundene Steuerelemente aus der Feldliste in das Formular ziehen.<\/p>\n Die Bindung der Steuerelemente an die Datensatzquelle funktioniert nämlich nach dem Zuweisen eines Recordsets genauso wie mit einer direkt für die Eigenschaft Datensatzquelle <\/b>angegebenen Tabelle oder Abfrage.<\/p>\n Dazu legen wir ein neues, leeres Formular namens frmKunden <\/b>an und fügen Datensatzquelle und Steuerelemente wie in Bild 3 hinzu.<\/p>\n Bild 3: Ausstatten des Formulars mit gebundenen Steuerelementen<\/span><\/b><\/p>\n Nun folgen die entscheidenden Schritte:<\/p>\n Listing 3: Das Ereignis Beim Öffnen<\/span><\/b><\/p>\n<\/ul>\n Öffnen wir das Formular nun in der Formularansicht, zeigt dieses die Daten wie in einem herkömmlichen gebundenen Formular an. Wir können in den Datensätzen blättern, neue Datensätze anlegen, vorhandene Datensätze bearbeiten und löschen.<\/p>\n Ein erstes Problem tritt auf, wenn wir über die eingebaute Funktion über das Kontextmenü nach einen Feld sortieren oder filtern wollen. Beim Versuch, zu sortieren, erscheint die Fehlermeldung aus Bild 4.<\/p>\n Bild 4: Fehler beim Versuch, die Datensätze im Formular zu sortieren<\/span><\/b><\/p>\n Wenn wir filtern wollen, zum Beispiel nach einem bestimmten Nachnamen, erscheint die Meldung aus Bild 5.<\/p>\n Bild 5: Fehler beim Versuch, im Formular zu filtern<\/span><\/b><\/p>\n Das sind zwei typische Fehler bei der ADODB-Recordset-Bindung in Kombination mit der eingebauten Access-Suche\/Filter-Funktion.<\/p>\n Geben Sie einen gültigen Wert ein<\/b> tritt auf, wenn Access intern versucht, über die Datensatzquelle des Formulars zu filtern, aber keine SQL-Datensatzquelle findet (weil wir keine eingetragen haben, sondern das Recordset per Code gesetzt haben).<\/p>\n Der Datenprovider konnte nicht initialisiert werden<\/b> tritt auf, wenn Access versucht, den eingebauten Filter- oder Suchmechanismus auf ein ADODB-Recordset anzuwenden, was nicht unterstützt wird.<\/p>\n Diese Funktionen setzen eine klassische DAO-gebundene Datensatzquelle voraus. Die Fehler treten bei allen drei Verbindungsarten auf, also bei Recordsets auf Basis der lokalen Datenbank, der Backend-Datenbank und auch beim SQL Server.<\/p>\n Wer allerdings den Aufwand nicht scheut, seine Datenbank auf die hier beschriebene Art zu schützen, wird sicher auch benutzerdefinierte Elemente zur Steuerung von Funktionen wie der Sortierung oder der Filterung programmieren.<\/p>\n Daher sehen wir das erst einmal nicht als Problem an. In einem weiteren Beitrag namens Filtern und Sortieren von Formularen mit Recordsets <\/b>(www.access-im-unternehmen.de\/****<\/b>) zeigen wir eine Lösung, wie sich dies mit eigenen Funktionen abbilden lässt.<\/p>\n Um das Frontend sicher zu machen, können wir nun die noch vorhandenen Tabellen oder Tabellenverknüpfungen aus dem Frontend entfernen.<\/p>\n Diese können wir später jederzeit wieder hinzufügen, beispielsweise wenn wir weitere Formulare anlegen wollen.<\/p>\n Öffnen wir das Formular frmKunden <\/b>nun erneut, stellen wir allerdings fest, dass die Anrede <\/b>nicht mehr angezeigt wird – und auch die Auswahlliste ist leer (siehe Bild 6).<\/p>\n Bild 6: Die Anreden werden nicht mehr angezeigt.<\/span><\/b><\/p>\n Das Problem ist schnell gefunden. Wir haben das Feld AnredeID <\/b>als Nachschlagefeld mit der Tabelle tblAnreden <\/b>als Datensatzherkunft in der Tabelle tblKunden <\/b>angelegt. Beim Hinzufügen des Feldes in das Formular wurden die Eigenschaften des Nachschlagefeldes in das Kombinationsfeld für dieses Feld übernommen. <\/p>\n Die Tabelle tblAnreden <\/b>ist allerdings nicht mehr in der lokalen Datenbank vorhanden, daher kann das Kombinationsfeld auch keine Daten anzeigen. <\/p>\n Kombinations- und Listenfelder haben aber auch eine Recordset<\/b>-Eigenschaft, sodass wir die Tabelle tblAnreden <\/b>leicht zuweisen können. Dazu benennen wir das Steuerelement AnredeID <\/b>erst einmal in cboAnredeID <\/b>um.<\/p>\n Die Ereignisprozedur Form_Open <\/b>erweitern wir um die folgende Anweisung:<\/p>\n Öffnen wir das Formular erneut, erscheinen auch die Anreden wieder – sowohl als ausgewählter Eintrag im Kombinationsfeld als auch in der Auswahlliste (siehe Bild 7).<\/p>\n Bild 7: Nach dem Setzen des Recordsets erscheinen auch die Anreden wieder.<\/span><\/b><\/p>\n Nun testen wir, ob wir auch in der Datenblattansicht eines Formulars mit einem Recordset arbeiten können. Dazu kopieren wir einfach das Formular frmKunden <\/b>in ein neues Formular namens frmKunden_Datenblatt<\/b>.<\/p>\n Hier nehmen wir lediglich eine Änderung vor: Wir stellen die Eigenschaft Standardansicht <\/b>des Formulars auf Datenblatt <\/b>ein.<\/p>\n Nach dem Öffnen des Formular scheint auf den ersten Blick alles zu funktionieren. Allerdings gibt es wieder ein Problem mit dem Suchen und Filtern.<\/p>\n Die Befehle des Popupmenüs, das erscheint, wenn man auf das nach unten zeigende Dreieck im Spaltenkopf zeigt, funktionieren nicht und liefern die von der Detailansicht bekannten Fehlermeldungen (siehe Bild 8).<\/p>\n Bild 8: Formular mit Recordset in der Datenblattansicht<\/span><\/b><\/p>\n Diese können wir noch abfangen, indem wir das Ereignis Bei Fehler <\/b>implementieren und dort beispielsweise die folgende Prozedur hinterlegen:<\/p>\n Damit geben wir den Fehler im Direktbereich aus und unterbinden die Fehlermeldung. Aber wir können nicht herausfinden, welche Aktion genau zum Fehler geführt hat, sonst ließe sich die aufgerufene Funktion mit ADODB nachbilden.<\/p>\n Tiefer wollen wir an dieser Stelle nicht in das Thema einsteigen. Stattdessen zeigen wir im Beitrag Filtern und Sortieren von Formularen mit Recordset <\/b>(www.access-im-unternehmen.de\/1602<\/b>), wie wir die Filter- und Sortierfunktionen weitgehend funktional gestalten können.<\/p>\n Alternativ dazu können Sie auch eigene Steuerelemente zum Filtern und Sortieren hinzufügen. Wie das gelingt, lesen Sie im Beitrag Filtern und Sortieren von Formularen mit Recordset <\/b>(www.access-im-unternehmen.de\/1602<\/b>).<\/p>\n In diesem ersten Teil der Beitragsreihe haben wir die Grundlage geschaffen, auf der alle weiteren Teile aufbauen: das Modul mdlADODB<\/b> mit seinen Hilfsfunktionen GetConnection<\/b> und GetRecordset<\/b>.<\/p>\n Mit einer einzigen Konstanten – cIntConnection<\/b> – steuern wir, ob die Anwendung auf die lokale Datenbank, ein kennwortgeschütztes Access-Backend oder einen SQL Server zugreift.<\/p>\n Alle Formulare der Anwendung rufen ausschließlich diese beiden Funktionen auf und müssen sich um Verbindungsstrings, Pfade und Kennwörter nicht kümmern.<\/p>\n Am Beispiel des Detailformulars frmKunden<\/b> haben wir gezeigt, wie sich ein Formular per Set Me.Recordset = GetRecordset(…)<\/b> an ein ADODB-Recordset binden lässt. Das Formular verhält sich dabei wie ein klassisch gebundenes Formular: Blättern, Neuanlage, Bearbeiten und Löschen funktionieren ohne zusätzlichen Code.<\/p>\n Auch Kombinations- und Listenfelder lassen sich auf dieselbe Weise mit Daten versorgen – über ihre eigene Recordset<\/b>-Eigenschaft. Das ist besonders dann wichtig, wenn die Tabellenverknüpfungen aus dem Frontend entfernt wurden und Nachschlagefelder ihre Daten nicht mehr automatisch beziehen können.<\/p>\n Die eingebauten Sortier- und Filterfunktionen von Access stehen bei ADODB-gebundenen Formularen nicht zur Verfügung – das ist ein bekanntes und bewusstes Zugeständnis an die höhere Flexibilität dieser Technik.<\/p>\n Wer seine Daten auf diesem Weg schützt, wird ohnehin eine eigene Benutzeroberfläche programmieren und auf die eingebauten Ribbon-Funktionen verzichten. Wie sich Sortierung und Filterung mit eigenen Mitteln umsetzen lassen, zeigen wir in einem separaten Beitrag.<\/p>\n Im nächsten Teil der Reihe wenden wir dieselbe Technik auf Formulare in der Datenblattansicht an. Dort gibt es einige Besonderheiten zu beachten – etwa beim Zusammenspiel von Recordset-Bindung und den Spalten des Datenblatts. Danach folgen Haupt- und Unterformulare, bei denen wir zwei synchronisierte Recordsets verwalten müssen, sowie Listen- und Kombinationsfelder, deren Datenbindung wir vollständig selbst übernehmen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n DetailformularUndDatenblattMitADODBRecordset.accdb<\/p>\n DetailformularUndDatenblattMitADODBRecordset_BE.accdb<\/p>\nADODB-Bibliothek referenzieren<\/h2>\n
![\"Verweis](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_002.png\")
<\/p>\nVBA-Funktionen für den Zugriff auf Connection und Recordset<\/h2>\n
'Art der Verbindung:\r\n'1 = CurrentProject.Connection\r\n'2 = Access-Backend (.accdb)\r\n'3 = SQL Server\r\nPrivate <\/span>Const cIntConnection As Integer<\/span> = 2<\/pre>\n'Verbindungsstring für Access-Backend (ACE-Provider)\r\nPrivate <\/span>Const strCnnAccess As String<\/span> = _\r\n \"Provider=Microsoft.ACE.OLEDB.12.0;Data Source=\"\r\n'Verbindungsstring für SQL Server (Windows-Authentifiz.)\r\nPrivate <\/span>Const strCnnSQLServer As String<\/span> = _\r\n \"Provider=MSOLEDBSQL;Server=amvDesktop2023;\" & _\r\n \"Database=ADODBRecordsets;Trusted_Connection=Yes;\"<\/pre>\n'Dateiname des Access-Backends\r\nPrivate <\/span>Const strDBName As String<\/span> = _\r\n \"FormulareMitADODBRecordset_BE.accdb\"\r\n'Datenbankpasswort des Access-Backends\r\nPrivate <\/span>Const strDBPasswort As String<\/span> = \"kennwort\"\r\nPrivate Function <\/span>GetDBPfad() As String<\/span>\r\n GetDBPfad = CurrentProject.Path & \"\\\" & strDBName\r\nEnd Function<\/span><\/pre>\nDie Funktion GetConnection<\/h2>\n
Public Function <\/span>GetConnection() As <\/span>ADODB.Connection\r\n Dim <\/span>cnn As <\/span>ADODB.Connection\r\n Dim <\/span>strConn As String<\/span>\r\n Select Case cIntConnection\r\n Case <\/span>1\r\n 'CurrentProject.Connection wiederverwenden\r\n Set<\/span> GetConnection = CurrentProject.Connection\r\n Exit Function<\/span>\r\n Case <\/span>2\r\n 'Access-Backend: Verbindungsstring zusammenstellen\r\n strConn = strCnnAccess & GetDBPfad()\r\n If <\/span>strDBPasswort <> \"\" Then<\/span>\r\n strConn = strConn & \";Jet OLEDB:Database Password=\" & strDBPasswort\r\n End If<\/span>\r\n Case <\/span>3\r\n 'SQL Server: Verbindungsstring direkt verwenden\r\n strConn = strCnnSQLServer\r\n End Select<\/span>\r\n Set<\/span> cnn = New<\/span> ADODB.Connection\r\n cnn.Open strConn\r\n Set<\/span> GetConnection = cnn\r\nEnd Function<\/span><\/pre>\nDie Funktion GetRecordset<\/h2>\n
Public Function <\/span>GetRecordset(ByVal strSQL As String<\/span>, Optional<\/span> ByVal lngCursorType As Long<\/span> = adOpenStatic, _\r\n Optional<\/span> ByVal lngLockType As Long<\/span> = adLockOptimistic) _\r\n As <\/span>ADODB.Recordset\r\n Dim <\/span>cnn As <\/span>ADODB.Connection\r\n Dim <\/span>rst As <\/span>ADODB.Recordset\r\n Set<\/span> cnn = GetConnection()\r\n Set<\/span> rst = New<\/span> ADODB.Recordset\r\n rst.CursorLocation = adUseClient\r\n rst.Open strSQL, cnn, lngCursorType, lngLockType\r\n Set<\/span> GetRecordset = rst\r\nEnd Function<\/span><\/pre>\nDie Testprozedur<\/h2>\n
Public Sub <\/span>Test_GetRecordset()\r\n Dim <\/span>rst As <\/span>ADODB.Recordset\r\n Set<\/span> rst = GetRecordset( _\r\n \"SELECT TOP 10 * FROM tblKunden\")\r\n Do While<\/span> Not<\/span> rst.EOF\r\n Debug.Print<\/span> rst!KundeID, rst!Firma\r\n rst.MoveNext<\/span>\r\n Loop<\/span>\r\nEnd Sub<\/span><\/pre>\nDetailformular mit Recordset füllen<\/h2>\n
![\"Ausstatten](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_003.png\")
<\/p>\n\n
Private Sub <\/span>Form_Open(Cancel As Integer<\/span>)\r\n Set<\/span> Me.Recordset = GetRecordset(\"SELECT * FROM tblKunden\")\r\nEnd Sub<\/span><\/pre>\n![\"Fehler](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_005.png\")
<\/p>\n![\"Fehler](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_006.png\")
<\/p>\nTabellen aus dem Frontend entfernen<\/h2>\n
![\"Die](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_008.png\")
<\/p>\nSet<\/span> Me.cboAnredeID.Recordset = GetRecordset( _\r\n \"SELECT * FROM tblAnreden\")<\/pre>\n![\"Nach](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_009.png\")
<\/p>\nDatenblattansicht mit Recordset<\/h2>\n
![\"Formular](\"..\/fileadmin\/_temp_\/2026_03\/pic_1601_010.png\")
<\/p>\nPrivate Sub <\/span>Form_Error(DataErr As Integer<\/span>, _\r\n Response As Integer<\/span>)\r\n Debug.Print<\/span> DataErr, AccessError(DataErr)\r\n Response = acDataErrContinue\r\nEnd Sub<\/span><\/pre>\nZusammenfassung und Ausblick<\/h2>\n
Downloads zu diesem Beitrag<\/h2>\n