{"id":55000588,"date":"2008-04-01T00:00:00","date_gmt":"2021-02-11T21:20:29","guid":{"rendered":"http:\/\/access-im-unternehmen.aix-dev.de\/aiu\/?p=588"},"modified":"-0001-11-30T00:00:00","modified_gmt":"-0001-11-30T00:00:00","slug":"Von_Access_nach_MySQL_Teil_2","status":"publish","type":"post","link":"https:\/\/access-im-unternehmen.de\/Von_Access_nach_MySQL_Teil_2\/","title":{"rendered":"Von Access nach MySQL, Teil 2"},"content":{"rendered":"

\"\"<\/p>\n

In der letzten Ausgabe des Magazins haben Sie erfahren, wie man mit einem Access-Backend und dem kostenlosen Migration Toolkit auf einen MySQL-Server umziehen kann. Sie haben vielleicht das Beispiel nachvollzogen und die Datenbank Südsturm von Access im Unternehmen nun in MySQL-Tabellen vorliegen. Nach diesem Schritt steht die Anbindung dieser Tabellen an ein Access-Frontend an. Wie Sie dabei vorgehen und wie auftretende Probleme gelöst werden können, das soll der folgende Beitrag erläutern.<\/b><\/p>\n

Sie müssen weder zwingend den ersten Teil dieser Serie verinnerlicht, noch das dort vorgestellte Südsturm-Beispiel durchgespielt haben.<\/p>\n

Denn zu den diesen Beitrag begleitenden Dateien gehört auch ein SQL-Skript Suedsturm_Backup.sql<\/b>, mit dem Sie die MySQL-Datenbank samt referenzieller Integrität herstellen können.<\/p>\n

Weil dies ein Vorgang ist, den Sie auch später immer mal wieder bei der Arbeit mit MySQL benötigen, sei das Sichern einer MySQL-Datenbank in einer einzigen Datei hier zunächst kurz aufgezeigt.<\/p>\n

Backup erstellen<\/b><\/p>\n

Starten Sie den MySQL Administrator <\/b>aus der GUI-Suite von MySQL [2]. Sie werden mit einem Login-Dialog konfrontiert, in dem Sie die notwendigsten Anmeldedaten angeben (siehe Bild 1).<\/p>\n

\"missing<\/p>\n

Bild 1: Anmelden an MySQL Administrator für eine Verwaltungs-Session<\/span><\/b><\/p>\n

Interessant sind dabei nur die Felder Server Host<\/b>, Nutzername <\/b>und Passwort<\/b>. Für Server Host <\/b>ist bei lokal installiertem MySQL-Server localhost <\/b>anzugeben und ansonsten der Name des Servers oder dessen IP-Nummer.<\/p>\n

Als Benutzername verwenden wir zunächst den immer existierenden Benutzer root<\/b>, dessen Passwort bereits beim Installieren des MySQL-Servers vergeben wurde.<\/p>\n

Sollten schon zusätzliche Benutzer angelegt worden sein, dann können Sie hier natürlich auch einen alternativen Account angeben. Wichtig ist aber, dass dieser Account über Berechtigungen zum Anlegen von Datenbanken (Schemata) verfügt. <\/p>\n

Nachdem der MySQL Administrator <\/b>gestartet wurde, finden Sie im Menü den Punkt Backup<\/b>. Wenn Sie diesen aktivieren, dann zeigt sich Ihnen eine Liste der auf dem Server befindlichen Datenbanken, in der aber noch kein Eintrag ausgewählt werden kann (siehe Bild 2). Erst muss nämlich ein Backup-Projekt mit der Schaltfläche Neues Projekt <\/b>angelegt werden.<\/p>\n

\"missing<\/p>\n

Bild 2: Die Tabellen für ein Backup im MySQL-Administrator<\/span><\/b><\/p>\n

Falls der Backup-Vorgang später öfters wiederholt werden soll, dann vergeben Sie im Feld Projektname <\/b>außerdem einen aussagekräftigen Namen wie Südsturm_Backup <\/b>und betätigen die Schaltfläche Projekt speichern<\/b>. Er erscheint damit in der Liste der Backup-Projekte links und kann aus dieser immer wieder aufgerufen werden.<\/p>\n

Die Liste der verfügbaren Schemata ist nun aktiv, Sie können daraus eine Datenbank auswählen und mit der Pfeil rechts<\/b>-Schaltfläche zum Backup-Inhalt hinzufügen.<\/p>\n

Standardmäßig werden dabei alle Tabellen der Datenbank für das Backup berücksichtigt. Ein Teil-Backup ist möglich, indem Sie einzelne Tabellen abwählen. Sollten später der Datenbank neue Tabellen hinzugefügt werden, dann müssen diese manuell in das Backup-Projekt integriert werden.<\/p>\n

Einfacher ist es aber, Sie schalten auf den Reiter Erweiterte Einstellungen <\/b>um und aktivieren die Checkbox Vollständiges Backup <\/b>– neue Tabellen werden dann später automatisch berücksichtigt.<\/p>\n

Das Backup stellen Sie anschließend mit Klick auf die Schaltfläche Backup jetzt durchführen <\/b>fertig. Dabei werden Sie in einem Speichern<\/b>-Dialog dazu aufgefordert, einen Dateinamen für das Skript anzugeben – etwa suedsturm_backup.sql<\/b>. Das erfolgreich exportierte SQL-Skript enthält nichts weiter als eine Aneinanderreihung von DDL-Anweisungen, aus dem die Datenbank von Grund auf neu erstellt werden kann. Mit INSERT-Statements werden auch die Daten wiederhergestellt.<\/p>\n

Bliebe noch zu erwähnen, dass dieses Backup auch automatisiert durchgeführt werden kann, wenn über den Registerreiter Zeitplanung entsprechende Angaben gemacht werden. Weitere Ausführungen zum Vorgehen dabei finden Sie in der Hilfe zum MySQL Administrator<\/b>.<\/p>\n

Backup wiederherstellen<\/b><\/p>\n

Aus dem SQL-Skript können Sie sehr einfach eine Datenbank wiederherstellen, indem Sie den Menüpunkt Wiederherstellung <\/b>im MySQL Administrator <\/b>aktivieren. Sie wählen die SQL-Datei suedsturm_backup.sql <\/b>über die Schaltfläche Datei öffnen <\/b>aus und klicken anschließend auf Starten<\/b>.<\/p>\n

Eine Fortschrittsanzeige informiert dann über die Wiederherstellung beziehungsweise das Neuanlegen der Datenbank. Die übrigen Einstellungen auf der Registerseite sind selbsterklärend und bedürfen im Normalfall keiner Modifikation.<\/p>\n

Machen Sie sich allerdings klar, dass mit dem Wiederherstellen-Vorgang eine möglicherweise existierende Datenbank gleichen Namens auf dem Server komplett gelöscht wird.<\/p>\n

Differenzielle Backups mit ausgeklügelten Optionen, die etwa Microsoft SQL Server <\/b>vorsieht, sind mit den Bordmitteln des MySQL Administrators <\/b>nicht möglich. Solche Backup-Tools sind für MySQL nur gegen gutes Geld zu haben.<\/p>\n

Hier wird deutlich, dass Backups sich hervorragend dazu eignen, um Datenbanken von einem Server zum anderen zu transferieren. Entwickeln Sie Ihre Datenbank etwa auf dem lokalen MySQL-Server und speichern Sie nach Abschluss der Entwicklung über ein Backup das Ganze auf einen USB-Stick.<\/p>\n

Beim Kunden stellen Sie aus der SQL-Datei die komplette Datenbank wieder her und haben ihn damit mit Ihrem neuesten Werk beglückt. Selbstverständlich lässt sich das alternativ statt über USB-Stick oder einen anderen Datenträger auch direkt über eine VPN-Verbindung zum Kunden erledigen – Sie brauchen bei Anmeldung am MySQL Administrator <\/b>lediglich die IP des Kundenservers unter Server Host <\/b>einzutragen.<\/p>\n

ODBC-Treiber installieren<\/b><\/p>\n

Unser Ziel ist es ja, die Tabellen vom MySQL-Server auf gleiche Weise in ein Access-Frontend zu verknüpfen, wie dies auch mit einem MDB-Backend geschieht.<\/p>\n

Microsoft liefert aber verständlicherweise keinen nativen (ISAM-)Treiber für MySQL-Datenbanken. Die Verbindung geht über ODBC vonstatten. ODBC ist eine standardisierte Zwischenkommunikationsschicht zwischen einem SQL-Server und einem SQL-Client.<\/p>\n

Ein ODBC-Consumer (Access) hält dabei genauso das Protokoll ein wie der ODBC-Provider. Beim Provider handelt es sich um einen Treiber, der mittels eigenem API den Server über TCP\/IP-Ports oder Named Pipes <\/b>ansprechen kann.<\/p>\n

Nur er kennt die genauen Statements, die der SQL-Server verlangt, und kann mit den zurückgelieferten Ergebnissen etwas anfangen.<\/p>\n

Der ODBC-Treiber ist damit im Prinzip nichts anderes als ein übersetzer der standardisierten <\/p>\n

ODBC-SQL-Syntax in die Sprache, die der jeweilige SQL-Server versteht, und umgekehrt.<\/pre>\n
Für MySQL ist ein ODBC-Treiber unter [1] verfügbar, der MySQL Driver 3.51<\/b>. Vor einiger Zeit wurde er in MySQL Connector\/ODBC <\/b>umgetauft.<\/p>\n
Es gibt alternativ noch eine Version 5.1, die erweiterte Unicode-Kompatibilität aufweist, welche Sie aber besser noch nicht verwenden sollten, weil sie aus dem Beta-Stadium noch kaum heraus ist und auch sonst keine Vorteile bietet.<\/p>\n
Das Treiberpaket im MSI-Format installieren Sie per Doppelklick unter Administratorrechten auf dem Rechner. Optionen gibt es dabei nicht zu berücksichtigen.<\/p>\n
Datenquelle (DSN) anlegen<\/b><\/p>\n
Eigentlich können Sie nach Installation des Treibers sogleich eine Verknüpfung zu MySQL-Tabellen aus Access heraus ansteuern. Diese Verknüpfung und die notwendigen Einstellungen müssen Sie dann aber für jedes Frontend neu vornehmen, das auf die gleiche MySQL-Datenbank zugreift. <\/p>\n
Sinnvoll ist daher der Zwischenschritt über eine ODBC-Datenquelle, welche die Verbindungsdaten persistent in einer Datei oder in der Registry festhält. In Zukunft muss dann nur noch diese gespeicherte Verbindung aufgerufen werden. Die Verwaltung dieser Verbindungen erfolgt auf Ihrem Rechner über die Systemsteuerung und den ODBC-Datenquellen-Administrator. <\/p>\n
Unter Windows XP finden Sie diesen ODBC-Administrator über den Umweg Systemsteuerung|Verwaltung|Datenquellen (ODBC)<\/b>.<\/p>\n
Drei Registerkarten sind nun für das Neuanlegen oder Verwalten einer Datenquelle von Belang: Benutzer-DSN<\/b>, System-DSN<\/b>, Datei-DSN<\/b> (siehe Bild 3). DSN <\/b>bedeutet Database System Name<\/b>. Für welche Sie sich entscheiden, ist zunächst egal. Jede dieser Seiten zeigt die Schaltfläche Hinzufügen… <\/b>und Konfigurieren…<\/b><\/p>\n
 \"missing<\/p>\n
Bild 3: Der ODBC-Datenquellenadministrator von Windows<\/span><\/b><\/p>\n
So eingerichtete Datenquellen unterscheiden sich lediglich im Ort, an dem sie abgespeichert werden. Während bei der Datei-DSN die Verbindungsdaten in einer Textdatei gespeichert werden, die somit mobil ist, exportieren Benutzer-DSN und System-DSN die Einstellungen in die Registry – einmal im Zweig HKEY-CURRENT_USER <\/b>und im anderen Fall im Zweig HKEY_LOCAL_MACHINE<\/b>, jeweils unter \\Software\\ODBC\\ODBC.INI<\/b>.<\/p>\n
Der Knackpunkt: Dabei werden alle Daten inklusive des für die Verbindung notwendigen Passworts im Klartext abgespeichert. Wie mit diesem Problem umgegangen werden kann, folgt später bei der Beschreibung von DSNless Connections.<\/p>\n
Erstellen wir nun eine ODBC-Verbindung zur Südsturm-Datenbank auf dem MySQL-Server. Wählen Sie dazu Benutzer-DSN und Hinzufügen… <\/b>Sie werden dann zur Auswahl eines installierten ODBC-Treibers aufgefordert. Wählen Sie hier den MySQL ODBC 3.51 Driver <\/b>aus (siehe Bild 4).<\/p>\n
 \"missing<\/p>\n
Bild 4: Treiberauswahl beim Anlegen einer DSN-Datenquelle<\/span><\/b><\/p>\n
Um fortzufahren, klicken Sie auf die etwas unglücklich bezeichnete Schaltfläche Fertigstellen <\/b>– fertiggestellt wird hier nämlich noch nichts, sondern Sie gelangen damit zum treiberspezifischen Konfigurations-Dialog des MySQL Connectors <\/b>(siehe Bild 5). Hier können Sie nun den Namen für die Datenquelle angeben (Data Source Name<\/b>) und die gleichen Anmeldedaten festhalten, die Sie bereits vom Start der Anwendung MySQL Administrator <\/b>kennen: Server, Benutzer (User) und Passwort. Nachdem diese Grunddaten eingegeben wurden, füllt sich automatisch auch das Kombinationsfeld Database <\/b>mit den auf dem Server verfügbaren Datenbanknamen. Sie wählen hier natürlich suedsturm <\/b>aus.<\/p>\n
 \"missing<\/p>\n
Bild 5: Einstellungen des MySQL-Treibers (Connector) beim Anlegen einer DSN<\/span><\/b><\/p>\n
Ein Klick auf OK <\/b>würde diese Verbindung bereits speichern. Zuvor sollten aber dringend noch weitere Treibereinstellungen vorgenommen werden, die für das Zusammenspiel mit Access von Bedeutung sind. Wechseln Sie dazu zur Registerkarte Advanced <\/b>und aktivieren Sie Optionen wie in Bild 6.<\/p>\n
 \"missing<\/p>\n
Bild 6: Konfigurationsoptionen des ODBC-Treibers für eine MySQL-Verbindung <\/span><\/b><\/p>\n
Erläuterungen zur Wirkungsweise dieser Optionen führen hier zu weit und tief in die Funktionen der Datenbank-Engine. Fest steht jedenfalls, dass ohne diese gesetzten Optionen die Fehlerrate und Verbindungsprobleme unter Access zunehmen. <\/p>\n
Die einzelnen Flags stehen übrigens für Optionskonstanten, die sich später bei Zugriffen über VBA-Code auch setzen lassen. Eine Zusammenstellung dieser Konstanten finden Sie unter [3]. Die Konstellation der Abbildung ergibt übrigens eine zusammengesetzte Konstante mit dem Wert OPTION=43<\/b>.<\/p>\n
MySQL-Tabellen verknüpfen<\/b><\/p>\n
Mit der DSN-Datenquelle im Gepäck kann es nun richtig losgehen. Wie bei Access-Backends starten Sie die Verknüpfung über das Menü Datei|Externe Daten|Tabellen verknüpfen…<\/b><\/p>\n
<\/p>\n
Im Auswahldialog stellen Sie jedoch für Dateityp ODBC-Datenbanken() <\/b>ein. Im sich dadurch öffnenden Dialog markieren Sie unter Computerdatenquelle <\/b>die Datenverbindung Südsturm_MySQL<\/b>. <\/b>Abschließend erscheint noch ein Dialogfenster, in dem Sie alle Tabellen der Südsturm-Datenbank auswählen.<\/p>\n
Die Option zum Speichern des Kennworts können Sie auch gleich aktivieren. Die verknüpften Tabellen repräsentieren sich im Datenbankfenster nun mit einem anderen Symbol als bei Access-Backends (siehe Bild 7).<\/p>\n
 \"missing<\/p>\n
Bild 7: So sehen verknüpfte ODBC-Tabellen im Datenbankfenster aus.<\/span><\/b><\/p>\n
Und im Prinzip wars das schon: Sie können nun auf gewohnte Weise Abfragen, Formulare und Berichte auf Basis der Tabellen erstellen und damit genau so arbeiten, als hätten Sie ein Access-Backend im Einsatz.<\/p>\n
Zunächst wollen wir jedoch noch überprüfen, was Access und MySQL beim Verknüpfen aus den ursprünglichen Felddatentypen der suedsturm.mdb <\/b>gemacht haben.<\/p>\n
Dazu öffnen Sie die Tabellen im Entwurf und kontrollieren die einzelnen Felder. Sie werden feststellen, dass fast alle Datentypen identisch mit denen der Ursprungsdatenbank sind. Selbst die Indizes sind korrekt: Die ID-Felder (Primärschlüssel) werden als eindeutig indiziert ausgewiesen und Fremdschlüssel-IDs als indiziert mit Duplikaten.<\/p>\n
Abweichend werden Sie allerdings bemerken, dass die Primärschlüssel nicht mehr auf Autowert stehen – logisch, denn das Inkrementieren dieser Felder übernimmt nun MySQL selbst. Das Migration Kit <\/b>hat beim übertragen das Autowertfeld der Tabelle tblArtikel <\/b>etwa so definiert:<\/p>\n
'ArtikelID'' int(10) NOT NULL auto_increment<\/pre>\n
Zusätzlich fällt noch auf, dass das Währungsfeld Einzelpreis in Dezimal 19,4 <\/b>gewandelt wurde. Das ist so in Ordnung und bedeutet eine fixe Dezimalzahl mit vier Stellen hinter dem Komma.<\/p>\n
Wenn Sie das Feld später an ein Textfeld eines Formulars binden, wird allerdings zur Laufzeit das Währungssymbol fehlen. Das lässt sich aber leicht ändern: Tragen Sie im Tabellenentwurf im Eingabefeld Format <\/b>einfach Währung <\/b>oder Euro <\/b>ein. Diese Feldeigenschaft bleibt erhalten, obwohl Sie Access beim öffnen der Tabelle im Entwurf warnte, dass verschiedene Eigenschaften nicht geändert werden könnten.<\/p>\n
Das ist auch richtig, betrifft aber nur die Datentypen oder Attribute der Felder selbst. Eigenschaften der Felder beziehen sich jedoch auf die gespeicherte Verknüpfung und können geändert werden. Sie ändern nichts an den MySQL-Tabellen auf dem Server. <\/p>\n
Die den Tabellen hinzugefügten TIMESTAMP<\/b>-Spalten zeigen sich im Tabellenentwurf übrigens als Datumsfeld. Dass es sich dabei nicht wirklich um ein Datumsfeld handelt, erkennen Sie daran, dass das Feld gesperrt ist: öffnen Sie die Tabelle und versuchen Sie, ein Timestamp-Datum zu ändern oder einzugeben – es geht nicht. Access kann die Eingabe nicht in das binäre Timestamp-Format von MySQL zurückverwandeln.<\/p>\n
Beziehungen anlegen<\/b><\/p>\n
Es ist Geschmackssache, ob man im Beziehungsfenster von Access für ODBC-Tabellen Beziehungen anlegt. Denn diese Beziehungen haben keine wirkliche Auswirkung im Betrieb.<\/p>\n
Schließlich ist es Access unmöglich, auf MySQL einzuwirken und dort Modifikationen am Datenmodell vorzunehmen. Warum also sollte man sich dann die Mühe machen, das Datenmodell hier abzubilden Zwei Gründe sprechen dafür: Einmal führt das AutoVerknüpfen<\/b>-Feature von Access dazu, dass in Abfragen beim Hinzufügen von Tabellen gleich automatisch die JOIN-Linien angelegt werden, wenn eine Beziehung besteht, und zum anderen haben Sie im Beziehungsfenster des Frontends so immer einen überblick über die Abhängigkeiten der Tabellen, also über das Datenmodell.<\/p>\n
Sie können also wie gewohnt Tabellen in das Beziehungsfenster von Access einfügen und Felder übereinanderziehen, um Beziehungen herzustellen.<\/p>\n
Nicht möglich ist es aber, für diese Beziehungen referenzielle Integrität einzustellen und etwa Löschweitergaben zu bestimmen. Die zugehörigen Steuerelemente sind im entsprechenden Dialogfenster deaktiviert.<\/p>\n
Um referenzielle Integrität kümmert sich MySQL selbst, weil es seit der Version 5 des Servers auch Fremdschlüssel mit Aktualisierungs- und Löschweitergabe vorsieht.<\/p>\n
Formulare erstellen<\/b><\/p>\n
Auf Basis der verknüpften ODBC-Tabellen können nun Formulare erstellt werden. In der Beispieldatenbank Suedsturm_mysql.mdb <\/b>finden Sie bereits zwei Formulare, die erst fehlerfrei funktionieren, nachdem Sie alle Tabellen neu verknüpft haben.<\/p>\n
Dazu müssen erst alle vorhandenen Tabellen gelöscht werden, weil sie auf eine DSN-Quelle verweisen, die auf Ihrem Rechner nicht existiert. über eine Lösung zum Neuverknüpfen von ODBC-Tabellen per VBA erfahren Sie später mehr.<\/p>\n
Formular Artikelkategorien<\/b><\/p>\n
Rufen Sie das Formular frmKategorien <\/b>auf, das zum Bearbeiten von Kategorien für Südsturm-Artikel dient. „Prima!“, werden Sie sagen, „aber wo sind die Abbildungen geblieben, die in dieser Tabelle ursprünglich zu jeder Kategorie enthalten waren“ Ganz einfach: Sie sind weg! Hier haben wir es mit einer der wenigen Unzulänglichkeiten des Migration Toolkits <\/b>zu tun.<\/p>\n
Es exportiert OLE-Felder zwar korrekt in den MySQL-Feldtyp LONGBLOB<\/b>, den Access nach Verknüpfen der Tabelle wiederum als OLE-Feld ausweist. Der Inhalt der Datensätze wird aber offenbar nicht übertragen.<\/p>\n
Wie bekommt man den Inhalt nachträglich in die MySQL-Tabellen, wie kann man hier nacharbeiten Die Lösung ist denkbar einfach: Die OLE-Feldinhalte werden mit einer Anfügeabfrage aus dem ursprünglichen Access-Backend exportiert.<\/p>\n
Dazu öffnen Sie die Quelldatenbank suedsturm.mdb <\/b>und erstellen zunächst über die DSN-Datenquelle eine neue ODBC-Verknüpfung zur Tabelle tblKategorien<\/b>. Da diese Tabelle bereits existiert, wird sie als tblKategorien1 <\/b>verknüpft.<\/p>\n
Löschen Sie dann alle Datensätze in ihr entweder in der Datenblattansicht oder mit der SQL-Anweisung DELETE FROM tblKategorien1<\/b>.<\/p>\n
Anschließend benötigen Sie eine Anfügeabfrage, die den Inhalt des OLE-Felds von der einen in die andere Tabelle überträgt:<\/p>\n
INSERT INTO tblkategorien1 SELECT tblKategorien.* FROM tblKategorien;<\/pre>\n
Und tatsächlich ist nun alles so, wie es sein sollte, und das Formular frmKategorien <\/b>zeigt die Abbildungen nun im gebundenen OLE-Steuerelement an (siehe Bild 8).<\/p>\n
 \"missing<\/p>\n
Bild 8: Kategorienformular der Beispieldatenbank mit OLE-Bild aus MySQL-BLOB<\/span><\/b><\/p>\n
Wenn Sie keine Lust haben, diese Schritte hier manuell nachzuvollziehen, dann können Sie übrigens die MySQL-Datenbank auch mit dem Backup Suedsturm_backup2.sql <\/b>wiederherstellen, wie eingangs beschrieben.<\/p>\n
Das enthält die OLE-Daten bereits. In Notepad geöffnet werden Sie feststellen, dass dabei die binären Daten des Feldes Abbildung <\/b>in Form von Hexadezimal-Strings gespeichert sind.<\/p>\n
Formular Kunden<\/p>\n
Das zweite Formular in der Beispieldatenbank heißt frmKunden <\/b>und zeigt die Südsturm-Kunden inklusive ihrer Bestellungen in einem Unterformular. Auf den ersten Blick scheint hier alles zu klappen. Versuchen Sie aber einmal, sämtliche PersonalID<\/b>-Einträge der Bestellungen im Unterformular zu ändern.<\/p>\n
Früher oder später wird es zu einer Fehlermeldung kommen und der Datensatz nicht aktualisiert. Die Nummer des Fehlers ist 7776 und die Meldung lautet: „Reservierter Fehler. Es gibt keine Beschreibung für diesen Fehler.“<\/p>\n
Suspekt dabei ist, dass auch die Errors<\/b>-Auflistung der DBEngine<\/b>, die normale Fehler des ODBC-Treibers protokolliert – Ausführungen dazu folgen – keine weiteren Angaben liefert. <\/p>\n
Der Grund für den Fehler zeigt sehr schön die Notwendigkeit von TIMESTAMP<\/b>-Feldern in MySQL-Tabellen, wenn sie nach Access verknüpft werden und keine Probleme beim Aktualisieren oder Löschen von Datensätzen auftreten sollen.<\/p>\n
Im ersten Teil dieser MySQL-Serie hatten wir zwar nach dem Migrationsprozess manuell Timestamp-Felder in die Tabellen aufgenommen und sie mit dem Vorgabewert CURRENT_TIMESTAMP <\/b>ausgestattet.<\/p>\n
Das hat aber noch nicht dazu geführt, dass diese Felder auch tatsächlich mit Timestamp-Werten gefüllt wurden – sie sind leer und haben den Wert Null<\/b>. Damit kann Access nichts anfangen. Die Timestamp-Felder müssen nachträglich über eine Aktualisierungsabfrage mit Werten versehen werden.<\/p>\n
Sowenig sie aber Timestamps in der Datenblattansicht der Tabelle ändern können, sowenig geht das über eine Abfrage – Sie erhalten die Meldung Feld nicht aktualisierbar<\/b>.<\/p>\n
Es gibt nun zwei Wege, um die Abfrage dennoch auszuführen: Entweder Sie benutzen den Query Browser aus der GUI-Suite von MySQL [2] oder Sie führen eine Pass-Through<\/b>-Abfrage aus, die direkt auf den MySQL-Server zugreift.<\/p>\n
Pass-Through-Abfrage erstellen<\/b><\/p>\n
Sie öffnen dazu eine neue Abfrage, fügen aber keine Tabelle hinzu. Wechseln Sie den Abfragetyp über das Menü Abfrage|SQL-spezifisch|Pass-Through<\/b>.<\/p>\n
Nun können Sie ausschließlich SQL-Anweisungen im Editor eingeben, dafür aber in der Syntax des MySQL-Servers, die einen erheblich größeren Umfang hat als der JET-Dialekt. VBA-Funktionen oder Bezüge zu Formularfeldern sind in den SQL-Anweisungen nicht möglich. Als Anweisung zum Setzen der Timestamp-Felder schreiben Sie etwa:<\/p>\n
UPDATE tblBestellungen SET TS=20080101000000;<\/pre>\n
Jedes Timestamp-Feld TS <\/b>wird hier mit einem dem Datum 01.01.2008 <\/b>analogen Wert gefüllt. Wenn Sie die Abfrage nun ausführen, dann wird der Dialog zur Auswahl einer DSN erscheinen.<\/p>\n
Access weiß zwar durch den Abfragetyp nun, dass Sie eine ODBC-Abfrage ausführen möchten, nicht jedoch, zu welchem Server es sich verbinden soll. Nach Auswahl der DSN Südsturm_MYSQL <\/b>ist dann die Timestamp-Spalte gefüllt.<\/p>\n
Access meldet: Die Abfrage hat keine Datensätze zurückgegeben<\/b>. Diese Meldung scheint überflüssig, weil wir ja keine Auswahlabfrage ausführen.<\/p>\n
Access kann das aber nicht ahnen, weil es die SQL-Anweisung selbst nicht analysiert oder interpretiert. Der SQL-String geht unbesehen direkt an den Server – daher die Bezeichnung Pass-Through<\/b>. <\/p>\n
Damit Sie diese Meldung nicht mehr zu Gesicht bekommen und außerdem das öffnen des Dialogs für ODBC-Datenquellen vermeiden, können Sie die Eigenschaften der Abfrage modifizieren.<\/p>\n
Zeigen Sie diese über das Menü Ansicht|Eigenschaften <\/b>an. Für Liefert Datensätze <\/b>geben Sie Nein <\/b>an und für die ODBC-Verbindung klicken Sie die Schaltfläche mit den Pünktchen an und wählen nun die DSN aus. Der ODBC-Connection-String ist jetzt als Eigenschaft der Abfrage gespeichert.<\/p>\n
Wiederholen Sie die Pass-Through<\/b>-Abfrage für jede Tabelle der Südsturm-Datenbank. Sie werden danach feststellen, dass das Unterformular sfrmBestellungen <\/b>keine Fehler mehr erzeugt und die Datensätze ordnungsgemäß aktualisiert. Der Inhalt der Timestamp-Felder ist für die JET-Engine notwendig, um Rückmeldungen zum Status der Datensätze zu erhalten.<\/p>\n
Fehler ermitteln<\/b><\/p>\n
Wenn sich in VBA ein Fehler ereignet, so können Sie dessen Nummer und Beschreibung einfach aus dem Err<\/b>-Objekt auslesen. Dabei spielt es keine Rolle, welches die Quelle des Fehlers war: Sowohl VBA-Fehler wie auch Fehler der JET-Engine werden im Err<\/b>-Objekt festgehalten.<\/p>\n
Meldet jedoch ein SQL-Server über ODBC einen Fehler, dann wird die Sache komplizierter. Da die JET-Engine auch hier nicht unbeteiligt ist, löst sie einen Fehler aus, der im Err<\/b>-Objekt gesetzt wird.<\/p>\n
Zusätzlich füllt sich aber auch die Errors<\/b>-Auflistung des DBEngine<\/b>-Objekts. Auflistung bedeutet, dass sich bei einem Datenvorgang gleich mehrere Fehler ereignet haben können, die chronologisch in einzelnen DAO.Error<\/b>-Objekten protokolliert werden.<\/p>\n
Denn je nachdem, welche Folgen eine Operation auf dem Server hat, kann ein auslösender Fehler weitere nach sich ziehen. In den meisten Fällen wird der ODBC-Treiber allerdings nur einen Fehler melden.<\/p>\n
Eine Fehlerbehandlung muss nun beide Fehlerarten berücksichtigen. Das zum Hauptformular frmKunden <\/b>gehörende Unterformular sfrmBestellungen <\/b>enthält exemplarisch eine solche Fehlerhandlung im Ereignis Bei Fehler <\/b>(Form_Error<\/b>):<\/p>\n
Private Sub Form_Error(DataErr As Integer, _\r\n    Response As Integer)\r\n    Select Case DataErr<\/pre>\n
    Case Else<\/pre>\n
    DBEngine.Errors.Refresh<\/pre>\n
    If DBEngine.Errors.Count > 0 Then<\/pre>\n
        Dim oErr As DAO.Error<\/pre>\n
        Dim sError As String<\/pre>\n
        For Each oErr In DBEngine.Errors<\/pre>\n
            sError = oErr.Source & "\/" _<\/pre>\n
            & oErr.Description & vbCrLf<\/pre>\n
        Next oErr<\/pre>\n
        MsgBox sError, vbExclamation, _<\/pre>\n
        "MySQL-Datenbankfehler"<\/pre>\n
    End If<\/pre>\n
    Response = acDataErrDisplay<\/pre>\n
    Me.Undo<\/pre>\n
    End Select<\/pre>\n
    End Sub<\/pre>\n
Es wird zunächst im Select Case<\/b>-Statement die vom Ereignis zurückgegebene Fehlernummer ausgewertet, damit auf jeden Fehler mit einer aussagekräftigen Meldung reagiert werden kann. Implementiert ist das indessen in dieser einfachen Routine nicht – alle Fehler laufen auf den Case Else<\/b>-Zweig.<\/p>\n
Dann wird ermittelt, ob die Errors<\/b>-Auflistung der DBEngine <\/b>Fehler protokolliert hat. Falls ja, dann werden alle in einer Schleife zu einem Meldungstext zusammengesetzt, der anschließend über eine Messagebox angezeigt wird. Das Setzen des Rückgabeparameters Response <\/b>auf acDataErrDisplay <\/b>führt dazu, dass nach dem Verlassen der Prozedur zusätzlich auch die normale Fehlermeldung der JET-Engine angezeigt wird, wie sie auch ohne diese Ereignisprozedur auftritt.<\/p>\n
Sie sollten übrigens in einer solchen Fehlerbehandlung immer zuerst die Errors<\/b>-Auflistung mit der Anweisung Refresh <\/b>aktualisieren. Es kommt nämlich hin und wieder vor, dass der Inhalt der Errors<\/b>-Auflistung nicht synchron zur auslösenden Meldung des ODBC-Treibers ist.<\/p>\n
Ausprobieren können Sie das, indem Sie absichtlich einen Fehler provozieren, was gar nicht ganz einfach ist. „ndern Sie etwa im MySQL Administrator <\/b>das Feld VersandUeber<\/b>, indem Sie dessen Eigenschaft Not Null <\/b>aktivieren. Es darf dann nicht mehr leer sein. Im Unterformular Bestellungen <\/b>versuchen Sie nun, in einem Datensatz den Eintrag für die Versandfirma zu löschen. MySQL wird zurückmelden, dass dies Schlüsselverletzungen nach sich zöge, und führt den Vorgang nicht aus.<\/p>\n
Der ODBC-Treiber gibt dabei einen detaillierten Hinweis darüber aus, was schiefgegangen ist. In unserem Beispiel wäre das die Regelverletzung a foreign key contraints fails<\/b>, die besagt, dass eine Fremdschlüsselverletzung auftrat, weil das Löschen der Versandfirma dem Setzen des Felds auf Null gleichkäme, was nicht erlaubt ist, weil eine Beziehung zu einem Datensatz der Tabelle tblVersandfirmen <\/b>bestehen muss. Außerdem wird die Regel, gegen die verstoßen wurde, als SQL-Statement ausgegeben:<\/p>\n
(nsuedsturm\/tblbestellungen'', CONSTRAINT 'tblVersandfirmentblBestellungen'' FOREIGN KEY ('VersandUeber'') REFERENCES 'tblversandfirmen'' ('FirmaID'') ON UPDATE CASCADE) (#1452)<\/pre>\n
Angehängt ist die Fehlernummer des MySQL-Servers. Sie können die Bedeutung solcher Nummern im Manual von MySQL nachschlagen oder online unter [4].<\/p>\n
Tabellen per VBA neu verknüpfen (DSNless Connection)<\/b><\/p>\n
Das gleiche Problem, das Sie mit Access-Backends haben, gibt es auch mit ODBC-Backends: Ihr Ort kann sich ändern und die Verknüpfungsangaben im Frontend sind nicht mehr korrekt. Selbstverständlich könnte man nun die Tabellen alle löschen und manuell neu verknüpfen. Das werden Sie wahrscheinlich dem Benutzer Ihrer Datenbank nicht zumuten wollen. Hier muss eine VBA-Routine her, welche die Verbindungsinformationen auffrischt.<\/p>\n
Ein Nebeneffekt der im Folgenden vorgestellten Prozedur: Sie macht das Anlegen einer DSN-Datenquelle auf dem Zielrechner überflüssig und verknüpft die Tabellen DSNless<\/b>. Die komplette Routine mit dem umfangreichen Hilfsmodul mdlODBCTool <\/b>finden Sie in der Beispieldatenbank suedsturm_mysql.mdb<\/b>. Hier kann aus Platzgründen nur der Kern der Neuverknüpfungsroutine dargestellt werden. Die wichtigste Information beim Neuverknüpfen ist der ODBC-Connection-String. Den liefert normal die gespeicherte DSN; er kann aber genauso gut in VBA zusammengesetzt werden. Er sieht etwa so aus:<\/p>\n
ODBC;Driver={MySQL ODBC 3.51 Driver};DATABASE=suedsturm; _\r\nSERVER=192.168.1.1;PORT=3306;UID=root;PWD=meinpasswort;OPTION=43;<\/pre>\n
Von den semikola-separierten Parametern ist eigentlich nur der für den Server variabel. Die anderen Parameter bleiben für eine Datenbank ohne spezielles Benutzersystem gleich. Dementsprechend kann man eine kleine Funktion basteln, die den Connection-String zurückgibt:<\/p>\n
Function GetODBCString() As String<\/pre>\n
    Dim strServer As String<\/pre>\n
    strServer = InputBox("Bitte Server " _\r\n    & "namentlich oder per IP angeben:", _<\/pre>\n
    "Verbindung zum Server", "localhost")<\/pre>\n
    If Len(strServer) = 0 Then Exit Function<\/pre>\n
    GetODBCString = _\r\n    "ODBC;Driver={MySQL ODBC 3.51 Driver}" _<\/pre>\n
    & ";DATABASE=suedsturm;SERVER=" _\r\n    & strServer & ";PORT=3306" _<\/pre>\n
    & ";UID=root;PWD=adminpasswort;"_\r\n    & "OPTION=43;"<\/pre>\n
End Function<\/pre>\n
Auf Basis dieses Connection-Strings können nun die Verbindungsinformationen aller Tabellen aufgefrischt werden (ersetzen Sie in der Beispieldatenbank das Passwort adminpasswort <\/b>durch Ihr eigenes). Hier ein Ausschnitt aus der Routine:<\/p>\n
sBase = GetODBCString(False)\r\nFor Each tdf In dbs.TableDefs<\/pre>\n
    If Left(tdf.Connect, 4) = "ODBC" Then<\/pre>\n
        sConx = sBase & "TABLE=" & tdf.Name & ";"<\/pre>\n
        If (tdf.Connect <> sBase) Then<\/pre>\n
            tdf.Connect = sBase<\/pre>\n
            tdf.RefreshLink<\/pre>\n
        End If<\/pre>\n
    End If<\/pre>\n
Next tdf<\/pre>\n
In der Routine werden alle TableDef<\/b>-Objekte der Datenbank durchlaufen und es wird zunächst überprüft, ob es sich um ODBC-Tabellen handelt, was am Präfix ODBC <\/b>für die Connect<\/b>-Eigenschaft ersichtlich wird.<\/p>\n
Dann wird getestet, ob der in der Verknüpfung gespeicherte Connect-String identisch mit dem über die Funktion GetODBCString <\/b>ermittelten ist. In diesem Fall ist nichts zu veranlassen. Andernfalls wird die Connect<\/b>-Eigenschaft neu gesetzt und mit der Anweisung RefreshLink <\/b>aktiviert.<\/p>\n
Eigentlich wäre das Neuverknüpfen damit beendet, gäbe es da bei ODBC-Frontends nicht noch eine Abweichung zu normalen Access-Frontends: Wir haben oben im Abschnitt Pass-Through<\/b>-Abfrage erstellen eine solche im Frontend angelegt und gespeichert.<\/p>\n
Dabei wurde in ihr die Eigenschaft ODBC-Verbindung gesetzt. Und die stimmt nun auch nicht mehr, sondern muss in die Neuverknüpfen-Routine einbezogen werden. Der Code dazu ist mit dem für Tabellenverknüpfungen fast identisch:<\/p>\n
For Each qdf In dbs.QueryDefs<\/pre>\n
    If Left(qdf.Connect, 4) = "ODBC" Then<\/pre>\n
        If (qdf.Connect <> sBase) Then<\/pre>\n
            qdf.Connect = sBase<\/pre>\n
        End If<\/pre>\n
        qdf.Close<\/pre>\n
    End If<\/pre>\n
Next qdf<\/pre>\n
Man kann die Routine zum Neuverknüpfen natürlich bei jedem Start der Frontend-Datenbank ausführen lassen. Unter Umständen dauert dieser Vorgang aber ziemlich lange und ist überflüssig, wenn sich der Server-Standort nicht geändert hat. Deshalb ist es sinnvoll, zuerst zu versuchen, eine Serververbindung herzustellen und nur dann ein Neuverknüpfen anzustoßen, wenn dies scheitert. Den Test übernimmt in der Beispieldatenbank die Funktion CanConnectBackend<\/b>. Sie gibt TRUE <\/b>zurück, falls die Verbindung zustande kommt. Die Funktion verwendet verschiedene API-Funktionen der odbc32.dll <\/b>und kann wegen ihres Umfangs hier nicht weiter erläutert werden. <\/p>\n
Beide Funktionen können nun in einer Startprozedur, die etwa vom AutoExec<\/b>-Makro angestoßen wird, so kombiniert werden:<\/p>\n
Function StartDB()<\/pre>\n
    If Not CanConnectBackend() Then<\/pre>\n
        If Not ChangeODBCConx() Then<\/pre>\n
            MsgBox "Es konnte keine Verbindung" _<\/pre>\n
            & "zum Server hergestellt " _\r\n            & "werden." & vbCrLf _<\/pre>\n
            & "Die Anwendung wird " _\r\n            & "beendet...", _<\/pre>\n
            vbCritical, "Südsturm"<\/pre>\n
            Application.Quit<\/pre>\n
        End If<\/pre>\n
    End If<\/pre>\n
End Function<\/pre>\n
Nur, wenn keine Verbindung zum Server hergestellt werden kann, läuft die Bedingung in die Routine zum Neuverknüpfen. Schlägt diese selbst fehl, dann wird der Anwender mit einer entsprechenden Meldung konfrontiert und die Datenbank beendet.<\/p>\n
MySQL-Tools<\/b><\/p>\n
Mit den Tools MySQL Administrator <\/b>und QueryBrowser <\/b>stellt MySQL zwar durchaus leistungsfähige Werkzeuge zur Verfügung, die den Vergleich mit kostenpflichtigen Programmen von Fremdanbietern nicht zu scheuen brauchen. Wer jedoch regelmäßig mit MySQL-Datenbanken arbeitet, der wird bald die zusätzlichen Möglichkeiten dieser Anwendungen schätzen lernen.<\/p>\n
Man muss nicht allzu tief in die Tasche greifen, um in den Genuss von Verwaltungstools zu kommen, die kaum Wünsche offen lassen. Für welches man sich entscheidet, ist Ansichtssache – eine Empfehlung möchte ich ungern aussprechen. Dennoch gibt es Unterschiede in Umfang, Oberflächenergonomie und Performance dieser Tools. Die meisten Hersteller bieten den Download von zeitlich eingeschränkten Testversionen an. Hier eine Liste der gebräuchlichsten Tools:<\/p>\n