<\/p>\n
Es gibt verschiedene Möglichkeiten, auf die Daten einer SQL Server-Datenbank zuzugreifen. Die einfachste Variante, wenn es um die Migration einer reinen Access-Datenbank in eine Kombination aus Access-Frontend und SQL Server-Backend geht, ist der Einsatz ODBC-verknüpfter Tabellen. Dabei werden die Tabellen einfach nur zum SQL Server migriert und man greift dann über ODBC-Verknüpfungen auf die Tabellen zu. Für den Zugriff auf diese Daten von Formularen aus ergeben sich so gut wie keine änderungen – und was sich doch ändern kann, erfahren Sie in diesem Beitrag.<\/b><\/p>\n
Wenn Sie eine Datenbank von Access zum SQL Server migrieren, übertragen Sie die Tabellen im Optimalfall 1:1 auf die SQL Server-Datenbank. Ist das der Fall, haben Sie recht gute Karten, dass Sie Ihre Anwendung recht schnell auch mit der neuen Datenherkunft läuft.<\/p>\n
Wie das geht Indem Sie einfach die Tabellen der SQL Server-Datenbank per ODBC mit der Access-Anwendung verknüpfen. Wenn Sie dabei darauf achten, dass die Verknüpfungen anschließend die gleichen Namen wie die zuvor verwendeten Tabellen haben, sollten die Abfragen, Formulare, Berichte und auch der VBA-Code, der auf die Daten zugreift, anstandslos funktionieren.<\/p>\n
Wir schauen uns das einmal an. In unserer Beispieldatenbank finden Sie zwei Formulare, die Ihnen bei der Verknüpfung der Tabellen behilflich sind und Ihnen viel Zeit sparen können. Das erste Formular heißt frmVerbindungszeichenfolgen<\/b>. Hier legen Sie mit der Schaltfläche Neu<\/b> eine neue Verbindungszeichenfolge an und geben dann ihre Eigenschaften ein. Ein Beispiel finden Sie in Bild 1 – hier testen wir auch gleich noch die Funktionalität der Verbindungszeichenfolge.<\/p>\n
![\"Verbindungszeichenfolge](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_001.png\")
<\/p>\n
Bild 1: Verbindungszeichenfolge definieren und testen<\/span><\/b><\/p>\n Das zweite hilfreiche Formular heißt frmTabellenVerknuepfen<\/b>. Mit diesem wählen Sie als Erstes die soeben definierte Verbindungszeichenfolge aus und selektieren dann bei gedrückter Strg<\/b>-Taste die zu verknüpfenden Tabellen – in diesem Fall tblArtikel<\/b>, tblBestelldetails<\/b>, tblBestellungen<\/b>, tblKategorien<\/b>, tblKunden<\/b>, tblLieferanten<\/b>, tblPersonal <\/b>und tblVersandfirmen <\/b>(siehe -Bild 2).<\/p>\n Bild 2: Hinzufügen der zu verknüpfenden Tabellen<\/span><\/b><\/p>\n Nach einem Klick auf die Schaltfläche Tabellen verknüpfen <\/b>landen die Verknüpfungen dann im Navigationsbereich, wo sie mit dem entsprechenden Symbol angezeigt werden (siehe Bild 3).<\/p>\n Bild 3: Die per ODBC verknüpften Tabellen<\/span><\/b><\/p>\n Die Tabellen wurden mit dem SQL Server Migrations-Assistenten für Access in eine SQL Server-Datenbank migriert. Dabei stellt dieser sicher, dass jede Tabelle ein Timestamp-Feld erhält. Dieses sieht in einer frisch migrierten Datenbank erst einmal wie in Bild 4 aus – das Feld ist zunächst scheinbar leer.<\/p>\n Bild 4: Tabelle mit Timestamp-Feld<\/span><\/b><\/p>\n Wenn Sie sich dieses Feld jedoch im SQL Server Management Studio ansehen, sind die Werte dieses Feldes mit Daten des Typs Bild 5: Tabelle mit Timestamp-Feld im SQL Server Management Studio<\/span><\/b><\/p>\n Warum aber wollen wir unsere SQL Server-Tabellen mit einem Zeitstempel versehen – und was ist der Zeitstempel, unter SQL Timestamp, überhaupt Zunächst einmal: Das Timestamp-Feld ist nicht etwa ein Feld, welches die aktuelle Systemzeit etwa beim ändern oder Anlegen eines Datensatzes speichert.<\/p>\n Es hat auch nicht das Format eines Datumsfeldes. Es ist vielmehr ein Feld, das einen binären Wert speichert, der beim Anlegen oder ändern eines Datensatzes eingetragen wird und der einzigartig ist.<\/p>\n Damit sorgen Sie für verschiedene Effekte:<\/p>\n Bevor Sie einen Datensatz im SQL Server nach der Bearbeitung etwa in einem Formular speichern können, muss der SQL Server prüfen, ob eventuell ein anderer Benutzer in der Zwischenzeit ebenfalls änderungen an diesem Datensatz durchgeführt hat. Ist das der Fall, erhalten Sie eine Meldung wie in Bild 6.<\/p>\n Bild 6: Fehlermeldung bei Schreibkonflikt<\/span><\/b><\/p>\n Wie lösen Sie diesen Fehler aus Dazu haben wir die Tabelle tblKategorien<\/b>, die in der Beispieldatenbank bereits ein Timestamp-Feld enthält, nochmals in eine neue Tabelle namens tblKategorien1 <\/b>kopiert, die kein Timestamp-Feld enthält. Außerdem haben wir für diese Tabelle eine ODBC-Verknüpfung namens tblKategorien1 <\/b>in der Access-Datenbank erstellt. Dann haben wir zwei Formulare namens frmKategorien1 <\/b>und frmKategorien2 <\/b>erstellt, die beide die ODBC-Verknüpfung tblKategorien1 <\/b>referenzieren.<\/p>\n Beide Formulare öffnen Sie und platzieren diese so, dass beide Formulare sichtbar sind. Dann ändern Sie den Datensatz im ersten Formular, speichern die änderung aber noch nicht. Hier setzen wir den Wert des Feldes Kategoriename <\/b>auf Kategorie 2<\/b>. Achten Sie darauf, dass der Datensatzmarkierer das Bearbeiten-Symbol anzeigt (siehe Bild 7).<\/p>\n Bild 7: ändern des Datensatzes im ersten Formular<\/span><\/b><\/p>\n Nun ändern Sie den Wert des gleichen Feldes im zweiten Formular auf Kategorie 3 <\/b>und speichern die änderung dort durch einen Klick auf den Datensatzmarkierer (siehe Bild 8). Schließlich versuchen Sie im Anschluss, auch die änderungen im ersten Formular per Klick auf den Datensatzmarkierer zu speichern. In diesem Moment erscheint die oben vorgestellte Meldung.<\/p>\n Bild 8: ändern und Speichern des Datensatzes im zweiten Formular<\/span><\/b><\/p>\n Die Meldung hält zwei Optionen bereit:<\/p>\n Interessanterweise gibt es noch eine zweite Konstellation, unter der eine Fehlermeldung beim ändern eines Datensatzes angezeigt wird – und zwar schon beim Versuch, auch nur den Inhalt eines Feldes zu bearbeiten. Um dies nachzustellen, verwenden Sie wieder die gleichen beiden Formular frmKategorien1 <\/b>und frmKategorien2<\/b>. Geben Sie nun in frmKategorien1 <\/b>für das Feld Kategoriename <\/b>beispielsweise den Wert Kategorie 0 <\/b>ein. Speichern Sie den Datensatz diesmal direkt.<\/p>\n Anschließend wechseln Sie zum Formular frmKategorien2 <\/b>und versuchen, den Inhalt des Feldes Kategoriename <\/b>anzupassen. Schon beim Eintippen des ersten Zeichens erscheint die Fehlermeldung aus Bild 9. Dies gilt übrigens für alle Steuer-elemente des Formulars.<\/p>\n Bild 9: Fehlermeldung beim Versuch, einen bereits geänderten Datensatz von einem anderen Formular aus nochmals zu ändern<\/span><\/b><\/p>\n Wichtig: Um dies reproduzieren zu können, muss der im anderen Formular editierte und gespeicherte Datensatz bereits im ersten Formular angezeigt werden. Wenn Sie den Datensatz erst nach der Bearbeitung im anderen Formular laden oder diesen erst aktualisieren, können Sie ihn ohne Probleme bearbeiten.<\/p>\n Aber woher kommt dieser Fehler Wir wollen erst einmal die Fehlernummer ermitteln, um dann weitere Nachforschungen anstellen zu können. Fehler, die in Formularen auftreten, aber nicht per VBA ausgelöst werden, kommt man nicht auf herkömmliche Weise auf die Spur – also indem man einfach die Fehlernummer per Err.Number <\/b>abfragt. Stattdessen müssen wir in diesem Fall wir die Ereignisprozedur Form_Error <\/b>bemühen, die wir für die Ereigniseigenschaft Bei Fehler <\/b>des Formulars anlegen (in diesem Fall nur für das Formular frmKategorien2<\/b>).<\/p>\n Die Ereignisprozedur statten wir zunächst nur mit einer einzigen Anweisung aus:<\/p>\n <\/p>\n Danach führen wir die oben angegebenen Schritte erneut aus. Dies liefert die Meldung aus Bild 10 mit der Nummer 7878<\/b>.<\/p>\n Bild 10: Ausgabe der Fehlernummer bei Reproduzierung des zweiten Fehlers<\/span><\/b><\/p>\n Wenn wir schon einmal dabei sind, können wir auch gleich die Fehlernummer des weiter oben ausgelösten Fehlers ermitteln. Dieser lautet, wie Bild 11 zeigt, nur etwas anders, nämlich 7787<\/b>.<\/p>\n Bild 11: Ausgabe der Fehlernummer bei Reproduzierung des ersten Fehlers<\/span><\/b><\/p>\n Um die Fehlertexte der beiden Fehler zu ermitteln, können wir die Funktion AccessError <\/b>im Direktbereich des VBA-Fensters absetzen. Für den Fehler 7878 <\/b>ergibt sich Folgendes:<\/p>\n Für den Fehler 7787 <\/b>liefert diese Funktion interessanterweise keine Fehlermeldung.<\/p>\n Wenn Sie denken, dass die Benutzer Ihrer Datenbankanwendung nicht mit der vom System erzeugten Meldung arbeiten können, lässt sich diese natürlich auch durch eine benutzerdefinierte Meldung ersetzen.<\/p>\n Für den Fehler 7787<\/b>, der beim zwischenzeitlichen ändern des gleichen Datensatzes an anderer Stelle ausgelöst wird, erledigen wir dies wie in Listing 1.<\/p>\n Listing 1: Neue Fehlermeldung für den Fehler mit der Nummer 7787<\/span><\/b><\/p>\n Dabei prüfen wir in einer Select Case<\/b>-Bedingung den Wert des Parameters DataErr<\/b>. Lautet dieser auf 7787<\/b>, zeigen wir eine Meldung an, die den Benutzer über das Problem und die Möglichkeiten aufklärt (siehe Bild 12). Aber wo sind hier im Vergleich zur Systemmeldung die beiden Auswahlmöglichkeiten Ganz einfach: Die haben wir herausgekürzt. In diesem Fall haben wir nämlich nicht die Möglichkeit, individuell auf die Benutzereingabe zu reagieren. Wie aber können wir dem Benutzer die Möglichkeit offen halten, dass er trotz der übernommenen änderungen durch einen anderen Benutzer dennoch seine eigenen änderungen durchsetzen kann Und geht das überhaupt, wenn wir die Ursprungsmeldung mit den beiden Optionen gar nicht mehr anzeigen <\/p>\n Bild 12: Neue, benutzerdefinierte Meldung beim Versuch, einen Datensatz zu ändern, der zwischenzeitlich an anderer Stelle geändert wurde.<\/span><\/b><\/p>\n Ja, das geht. Den Hinweis auf die Vorgehensweise geben wir in der Meldung. Nach dem Benutzer diese bestätigt hat, weisen wir dem Parameter Response <\/b>der Prozedur noch den Wert acDataErrContinue <\/b>zu. Das sorgt dafür, dass die Systemmeldung unterdrückt wird.<\/p>\n Immerhin sichert Access in diesem Fall aber den Inhalt des Datensatzes, den der aktuelle Benutzer bearbeitet hat, in der Zwischenablage – so kann dieser seine Version des Datensatzes über den durch den anderen Benutzer geänderten Datensatz kopieren.<\/p>\n Dies wollen wir auch noch für die Fehlermeldung erledigen, die ausgelöst wird, wenn ein anderer Benutzer den aktuellen Datensatz bearbeitet und speichert, bevor wir diesen selbst ändern. Um die Fehlermeldung für diesen Fall korrekt zu formulieren, schauen wir uns nochmal genau an, was beim Erscheinen der eingebauten Fehlermeldung geschehen ist. Hier stellen wir dann fest, dass sofort mit dem Eingeben des ersten Zeichens die im anderen Formular geänderte Version des Datensatzes erscheint. <\/p>\n Also können wir den Benutzer genau darauf hinweisen – dass der Datensatz seit dem Zeitpunkt des Anzeigens an anderer Stelle geändert wurde und diese nun auf den aktuellen Stand gebracht wurde (siehe Listing 2).<\/p>\n Listing 2: Neue Fehlermeldung für den Fehler mit der Nummer 7878<\/span><\/b><\/p>\n Es gibt zwei mögliche Probleme, die ohne ein Timestamp-Feld zur Anzeige von Fehlern führen können, ohne dass überhaupt eine andere änderung stattgefunden hat. Wir konnten in der Praxis nur eine der beiden reproduzieren, weisen aber dennoch auf beide hin:<\/p>\n Für SQL Server-Tabellen mit einem bit-Feld ist in diesem Feld ist normalerweise der Standardwert Null <\/b>eingestellt (also eigentlich kein Standardwert – das Feld bleibt schlicht leer).<\/p>\n Wenn Sie eine solche Tabelle in Access einbinden, wird das bit<\/b>-Feld mit dem Datentyp Ja\/Nein <\/b>abgebildet. Da das Ja\/Nein<\/b>-Feld keinen Nullwert kennt, zeigt etwa ein Formular für einen Datensatz mit dem Wert Null <\/b>ein nicht markiertes Kontrollkästchen an, also prinzipiell einen Nein<\/b>-Wert. Wenn Sie dann einen Datensatz ändern, der ein solches leeres bit<\/b>-Feld enthält, wird die weiter oben vorgestellte Meldung angezeigt.<\/p>\n Wir stellen das einmal nach. Dazu fügen Sie im SQL Server Management Studio der Tabelle tblKategorie1<\/b>, also der Version der Tabelle tblKategorien <\/b>ohne Timestamp-Feld, ein Feld namens Aktiv<\/b> mit dem Datentyp bit <\/b>hinzu. Die Spalte NULL-Werte zulassen <\/b>bleibt hier markiert (siehe Bild 13).<\/p>\n Bild 13: Hinzufügen eines bit-Feldes zur Tabelle<\/span><\/b><\/p>\n Danach fügen wir der Tabelle ebenfalls im SQL Server Management Studio einige Datensätze hinzu, sodass wir jeweils ein Exemplar mit den Werten True<\/b>, False <\/b>und NULL <\/b>im Feld Aktiv <\/b>haben (siehe Bild 14).<\/p>\n Bild 14: Eingeben einiger Beispieldaten<\/span><\/b><\/p>\n Da wir die Tabelle im SQL Server geändert haben, müssen wir die Verknüpfung mit der Access-Datenbank aktualisieren, was wir wie weiter oben beschrieben über das Formular frmTabelleVerknuepfen <\/b>erledigen. Anschließend können wir uns erst einmal ansehen, wie die Werte True<\/b>, False <\/b>und NULL <\/b>unter Access dargestellt werden. Dazu brauchen wir nur die Verknüpfung namens tblKategorien1 <\/b>zu öffnen.<\/p>\n Diese bietet den Anblick aus Bild 15. Sie sehen, dass schon hier nicht der Wert Null <\/b>angezeigt wird, sondern stattdessen der Wert 0<\/b>, also False<\/b>.<\/p>\n Bild 15: Das Feld Aktiv in der Datenblattansicht unter Access<\/span><\/b><\/p>\n Nun passen wir das Formular an, indem wir diesem ein neues Kontrollkästchen hinzufügen und dessen Eigenschaft Steuer-elementinhalt <\/b>auf das Feld Aktiv <\/b>einstellen (siehe Bild 16). Wenn wir das Feld Aktiv <\/b>einfach aus der Feldliste in den Formularentwurf ziehen würden, wäre das Resultat ein an das Feld Aktiv <\/b>gebundenes Textfeld statt eines Kontrollkästchens.<\/p>\n Bild 16: Hinzufügen des Kontrollkästchen-Steuerelements für das Feld Aktiv<\/span><\/b><\/p>\n Damit kommen wir zum Test des Verhaltens des Formulars, wenn wir die drei Datensätze nacheinander verändern, und zwar jeweils nicht im Feld Aktiv<\/b>.<\/p>\n Beim ersten Datensatz, wo das Feld Aktiv <\/b>den Wert -1 <\/b>enthält, lassen sich änderungen ohne Probleme durchführen und auch speichern. Das gleiche gilt für den dritten Datensatz, wo wir den Wert 0<\/b>, also False<\/b>, für das Feld Aktiv <\/b>hinterlegt haben.<\/p>\n Interessant wird es beim zweiten Datensatz, der den Wert Null <\/b>im Feld Aktiv <\/b>aufweist. Hier erscheint dann auch prompt unsere benutzerdefinierte Meldung, wo sonst die Meldung mit den beiden Optionen zum Speichern der eigenen änderungen in der Zwischenablage oder dem Verwerfen der eigenen änderungen erschienen wäre (siehe Bild 17).<\/p>\n Bild 17: Meldung beim ändern eines Datensatzes mit dem Wert Null in einem bit-Feld<\/span><\/b><\/p>\n Da wir den Datensatz offensichtlich zwischenzeitlich nicht verändert haben, ist ein anderes Problem für die Meldung verantwortlich – nämlich einen Type Mismatch-Fehler.<\/p>\n Was können wir tun Es gibt verschiedene Möglichkeiten:<\/p>\n In allen drei Fällen brauchen Sie sich zumindest für diese Konstellation nicht mehr um die Anpassung der Fehlermeldungen zu kümmern.<\/p>\n Als nächstes schauen wir uns ein Formular mit einem Unterformular an, dass an die per ODBC verknüpften Tabellen der SQL Server-Tabelle gebunden ist. Das Hauptformular soll die Tabelle tblKategorien <\/b>binden, das Unterformular an die Tabelle tblArtikel<\/b>. Dabei soll es alle Artikel zur jeweils im Hauptformular angezeigten Kategorie liefern.<\/p>\n Wenn wir Haupt- und Unterformular neu entwerfen und dann das Unterformular aus dem Navigationsbereich in den Entwurf des Hauptformulars ziehen, sieht dieses wie in Bild 18 aus. Sogar die beiden Eigenschaften Verknüpfen von <\/b>und Verknüpfen nach <\/b>werden korrekt eingestellt – Access erkennt also die Verknüpfungen auch auf dem SQL Server.<\/p>\n Bild 18: Entwurf von Haupt- und Unterformular<\/span><\/b><\/p>\n Diese werden allerdings, wie Bild 19 zeigt, beim Verknüpfen nicht automatisch in die Access-Anwendung übernommen, was ein Zeichen dafür ist, dass Access tatsächlich die Verknüpfungen auf dem SQL Server erkennt.<\/p>\n Bild 19: Fehlende Verknüpfungen im Datenmodell<\/span><\/b><\/p>\n Ein kleines Problem gibt es noch: Im Gegensatz zu Access, wo Sie bereits bei der Tabellendefinition ein Nachschlagefeld für Fremdschlüsselfelder einrichten konnten, geht dies beim SQL Server nicht. Nachschlagefelder sorgen dafür, dass beim Hineinziehen von Feldern, die als Nachschlagefeld ausgelegt sind, direkt Kombinationsfelder angelegt werden, welche die Daten der verknüpften Tabelle zur Auswahl anbieten. Im Fall der Felder LieferantID <\/b>und KategorieID <\/b>müssen wir also selbst tätig werden und die entsprechenden Eigenschaften nachträglich einrichten. Dabei ändern wir zunächst über den Kontextmenü-Eintrag ändern zu|Kombinationsfeld <\/b>des Textfeldes LieferantID <\/b>den Steuerelementtyp (siehe Bild 20).<\/p>\n Bild 20: ändern eines Textfeldes in ein Kombinationsfeld<\/span><\/b><\/p>\n In unserem Fall änderte sich durch diese Anpassung der Tab-Reihenfolge, die Sie über den Dialog Reihenfolge <\/b>wiederherstellen können (siehe Bild 21), zu öffnen über den Kontextmenü-Eintrag Aktivierreihenfolge… <\/b>eines der Steuerelemente im Unterformular. Damit die Kombinationsfelder auch Daten anzeigen, legen wir für die Eigenschaft Datensatzquelle <\/b>den folgenden Wert fest:<\/p>\n Bild 21: Wiederherstellen der Aktivierreihenfolge<\/span><\/b><\/p>\n Mit dem Wert 2 <\/b>für die Eigenschaft Spaltenanzahl <\/b>und 0cm <\/b>für Spaltenbreiten <\/b>sorgen wir noch dafür, dass nur die Firma angezeigt wird und nicht der Wert der gebundenen Spalte.<\/p>\n Auf die gleiche Weise passen Sie auch noch das Textfeld zur Anzeige der Kategorieauswahl an. Danach wechseln wir in die Formularansicht und sehen in Bild 22, dass die Anbindung des Formulars an die per ODBC verknüpften SQL Server-Tabellen wie gewünscht funktioniert.<\/p>\n Bild 22: Hauptformular mit Unterformular und Kombinationsfeldern auf Basis von per ODBC verknüpften Tabellen – es funktioniert wie erwartet.<\/span><\/b><\/p>\n Dieser Beitrag beleuchtet den Umgang mit Formularen, die an per ODBC verknüpfte Tabellen gebunden sind.<\/p>\n Wenn man ein paar Dinge beachtet, machen diese Tabellen keine Probleme und wir können lokale Access-Tabellen als Datenherkunft für einfache Formulare genutzt werden.<\/p>\n Auch wenn wir das Formular frmKategorienArtikel <\/b>hier neu erstellt haben, um zu demonstrieren, welche Schritte notwendig sind, um die fehlende Nachschlagefeld-Funktion im Tabellenentwurf des SQL Servers auszugleichen, lässt sich folgendes Fazit ziehen: Die per ODBC verknüpften Tabellen lassen sich in Formularen und ihren Steuerelementen ohne Probleme wie lokale Tabellen verwenden.<\/p>\n Für kleinere Probleme wie bit<\/b>-Felder, die Nullwerte enthalten und dadurch beim Bearbeiten von Datensätzen, die tatsächlich den Wert NULL <\/b>in einem solchen Feld enthalten, Datensatzsperrungen auslösen, haben wir Lösungen gezeigt.<\/p>\n Sogar das Bearbeiten von Datensätzen funktioniert reibungslos, sofern nicht der gleiche Datensatz parallel durch mehrere Benutzer bearbeitet wird.<\/p>\n Der Grund, weshalb wir dennoch ODBC-Verknüpfungen nur als ersten Schritte bei einer Migration oder für das Prototyping beim Neuerstellen einer Anwendung mit SQL Server-Backend nutzen sollten, ist die schlechte Performance.<\/p>\n Der Grund: Access holt sich hier erst einmal alle Daten der Datenherkunft und filtert oder sortiert erst auf dem Client-Rechner. Wenn Sie stattdessen etwa gespeicherte Prozeduren verwenden, erfolgt die Filterung bereits auf dem SQL Server und es werden nur die Daten über das Netz geschickt, die der Benutzer tatsächlich angefordert hat. Wie Sie dies realisieren, erfahren Sie in weiteren Beiträgen.<\/p>\n Enthaltene Beispieldateien:<\/p>\n ODBCVerknuepfungenInFormularen.zip<\/p>\n![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_002.png\")
<\/p>\n![\"Die](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_003.png\")
<\/p>\nZeitstempel<\/h2>\n
![\"Tabelle](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_004.png\")
<\/p>\n![\"Tabelle](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_005.png\")
<\/p>\n\n
Datensatzänderungen prüfen<\/h2>\n
![\"Fehlermeldung](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_006.png\")
<\/p>\n![\"ändern](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_007.png\")
<\/p>\n![\"ändern](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_008.png\")
<\/p>\n\n
Noch eine Fehlermeldung<\/h2>\n
![\"Fehlermeldung](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_009.png\")
<\/p>\nFehlernummer ermitteln<\/h2>\n
Private Sub <\/span>Form_Error(DataErr As Integer<\/span>, Response As Integer<\/span>)\r\n MsgBox<\/span> DataErr\r\nEnd Sub<\/span><\/pre>\n![\"Ausgabe](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_010.png\")
<\/p>\n![\"Ausgabe](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_011.png\")
<\/p>\n AccessError(7878)\r\nDie Daten wurden geändert.@Ein anderer Benutzer hat diesen Datensatz bearbeitet und die von ihm vorgenommenen änderungen gespeichert, bevor Sie versucht haben, Ihre änderungen zu speichern.@Bearbeiten Sie den Datensatz erneut.@1@@@1<\/pre>\n
Fehlermeldungen durch benutzerdefinierte Fehlermeldung ersetzen<\/h2>\n
Private Sub <\/span>Form_Error(DataErr As Integer<\/span>, Response As Integer<\/span>)\r\n Select Case DataErr\r\n Case <\/span>7878\r\n MsgBox<\/span> \"7878\"\r\n Case <\/span>7787\r\n MsgBox<\/span> \"Der Datensatz wurde in der Zwischenzeit an anderer Stelle geändert.\" & vbCrLf<\/span> & vbCrLf<\/span> _\r\n & \"Ihre änderungen werden verworfen, aber in der Zwischenablage gespeichert.\" & vbCrLf<\/span> & vbCrLf<\/span> _\r\n & \"Um Ihre Version zu übernehmen, markieren Sie den Datensatz und drücken Sie Strg + V.\"\r\n Response = acDataErrContinue\r\n Case Else<\/span>\r\n End Select<\/span>\r\nEnd Sub<\/span><\/pre>\n![\"Neue,](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_012.png\")
<\/p>\nFehlermeldung bei vorheriger änderung durch anderen Benutzer ersetzen<\/h2>\n
Private Sub <\/span>Form_Error(DataErr As Integer<\/span>, Response As Integer<\/span>)\r\n Select Case DataErr\r\n Case <\/span>7878\r\n MsgBox<\/span> \"Der Datensatz wurde in der Zwischenzeit an anderer Stelle geändert.\" & vbCrLf<\/span> & vbCrLf<\/span> _\r\n & \"Die Daten wurden soeben aktualisiert.\"\r\n Response = acDataErrContinue\r\n Case <\/span>7787\r\n ...\r\n Case Else<\/span>\r\n End Select<\/span>\r\nEnd Sub<\/span><\/pre>\nProbleme, die ein Timestamp-Feld erfordern<\/h2>\n
\n
Probleme mit bit-Feldern, die den Wert Null enthalten<\/h2>\n
![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_013.png\")
<\/p>\n![\"Eingeben](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_014.png\")
<\/p>\n![\"Das](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_016.png\")
<\/p>\nNullwert als Kontrollkästchen im Formular<\/h2>\n
![\"Hinzufügen](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_015.png\")
<\/p>\n![\"Meldung](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_017.png\")
<\/p>\n\n
Formular mit Unterformular<\/h2>\n
![\"Entwurf](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_018.png\")
<\/p>\n![\"Fehlende](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_019.png\")
<\/p>\n![\"ändern](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_020.png\")
<\/p>\n![\"Wiederherstellen](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_021.png\")
<\/p>\nSELECT tblLieferanten.LieferantID, tblLieferanten.Firma FROM tblLieferanten ORDER BY tblLieferanten.Firma;<\/pre>\n
![\"Hauptformular](\"..\/fileadmin\/_temp_\/2018_06\/pic_1164_022.png\")
<\/p>\nZusammenfassung und Ausblick<\/h2>\n
Downloads zu diesem Beitrag<\/h3>\n