Wenn Sie ein Abonnement des Magazins 'Access im Unternehmen' besitzen, können Sie sich anmelden und den kompletten Artikel lesen.
Anderenfalls können Sie das Abonnement hier im Shop erwerben.
ODBC-Verknüpfungen in Formularen
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.
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.
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.
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. Hier legen Sie mit der Schaltfläche Neu 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.
Bild 1: Verbindungszeichenfolge definieren und testen
Das zweite hilfreiche Formular heißt frmTabellenVerknuepfen. Mit diesem wählen Sie als Erstes die soeben definierte Verbindungszeichenfolge aus und selektieren dann bei gedrückter Strg-Taste die zu verknüpfenden Tabellen – in diesem Fall tblArtikel, tblBestelldetails, tblBestellungen, tblKategorien, tblKunden, tblLieferanten, tblPersonal und tblVersandfirmen (siehe Bild 2).
Nach einem Klick auf die Schaltfläche Tabellen verknüpfen landen die Verknüpfungen dann im Navigationsbereich, wo sie mit dem entsprechenden Symbol angezeigt werden (siehe Bild 3).
Zeitstempel
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.
Wenn Sie sich dieses Feld jedoch im SQL Server Management Studio ansehen, sind die Werte dieses Feldes mit Daten des Typs
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.
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.
Damit sorgen Sie für verschiedene Effekte:
- Sie vereinfachen die Untersuchung, ob ein Datensatz seit dem Beginn der Bearbeitung durch einen anderen Benutzer geändert wurde und ob eine entsprechende Meldung angezeigt werden muss.
- Sie verhindern Fehler, die durch unterschiedliche Fließkomma-Datentypen auftreten können.
Datensatzänderungen prüfen
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.
Wie lösen Sie diesen Fehler aus? Dazu haben wir die Tabelle tblKategorien, die in der Beispieldatenbank bereits ein Timestamp-Feld enthält, nochmals in eine neue Tabelle namens tblKategorien1 kopiert, die kein Timestamp-Feld enthält. Außerdem haben wir für diese Tabelle eine ODBC-Verknüpfung namens tblKategorien1 in der Access-Datenbank erstellt. Dann haben wir zwei Formulare namens frmKategorien1 und frmKategorien2 erstellt, die beide die ODBC-Verknüpfung tblKategorien1 referenzieren.
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 auf Kategorie 2. Achten Sie darauf, dass der Datensatzmarkierer das Bearbeiten-Symbol anzeigt (siehe Bild 7).
Nun ändern Sie den Wert des gleichen Feldes im zweiten Formular auf Kategorie 3 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.
Die Meldung hält zwei Optionen bereit:
- In Zwischenablage kopieren: Aktualisiert den Datensatz im Formular, wodurch die im zweiten Formular geänderte Version angezeigt wird. Die Version des Datensatzes, die im ersten Formular gespeichert wurde, landet dann in der Zwischenablage. Von dort können Sie diesen dann über den aktuellen Datensatz schreiben und doch noch speichern.
- Eigene Änderungen verwerfen: Diese Option verwirft einfach die Änderungen im ersten Formular und aktualisiert dieses mit dem im zweiten Formular geänderten Datensatz.
Noch eine Fehlermeldung
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 und frmKategorien2. Geben Sie nun in frmKategorien1 für das Feld Kategoriename beispielsweise den Wert Kategorie 0 ein. Speichern Sie den Datensatz diesmal direkt.
Anschließend wechseln Sie zum Formular frmKategorien2 und versuchen, den Inhalt des Feldes Kategoriename anzupassen. Schon beim Eintippen des ersten Zeichens erscheint die Fehlermeldung aus Bild 9. Dies gilt übrigens für alle Steuerelemente des Formulars.
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.
Fehlernummer ermitteln
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 abfragt. Stattdessen müssen wir in diesem Fall wir die Ereignisprozedur Form_Error bemühen, die wir für die Ereigniseigenschaft Bei Fehler des Formulars anlegen (in diesem Fall nur für das Formular frmKategorien2).
Die Ereignisprozedur statten wir zunächst nur mit einer einzigen Anweisung aus:
Private Sub Form_Error(DataErr As Integer, Response As Integer)
MsgBox DataErr
End Sub
Danach führen wir die oben angegebenen Schritte erneut aus. Dies liefert die Meldung aus Bild 10 mit der Nummer 7878.
Dies war die Leseprobe dieses Artikels.
Melden Sie sich an, um auf den vollständigen Artikel zuzugreifen.