mySQL & Access

mySQL ist ein DBMS aus der Linux/Unix-Welt, das seit einiger Zeit auch für Win32-Umgebungen verfügbar ist. Seit Ende Juni 2000 steht mySQL unter der GPL (GNU General Public Licence) und ist damit Open Source Software.

In der LAMP(Linux - Apache - MySQL - PHP)-Konstellation ist mySQL Teil einer der beliebtesten und am weitesten verbreiteten Software-Konfigurationen für datenbankgestützte Websites.

Besonderes Merkmal von mySQL ist die bewußt schlank gehaltene Datenbankengine, die in der Kategorie Performance wohl die meisten anderen DBMS aussticht. Schlank bedeutet aber auch, dass einige Features, die man von anderen DBMS gewöhnt ist, fehlen. So werden z.B. Transaktionen erst in der neuesten Version, Trigger, Cursor, Foreign Keys und Subselects bisher überhaupt nicht unterstützt.

Was hat das alles mit Access zu tun?

mySQL kann ein sehr kostengünstiges und leistungsstarkes Backend für Access-Applikationen sein. Natürlich kann es in Sachen Komfort und Funktionsumfang nicht mit dem MS-SQL-Server in Verbindung mit Access 2000-Projekten konkurrieren, dafür aber bei dem Preis um so mehr.

Bei direkter Intranet-Anbindung an den Server ist Access optimal als Datenpflege- und Reporting-Frontend für mySQL basierende Webapplikationen geeignet.

Für mich zwei überzeugende Gründe, die beiden Programme im Zusammenspiel zu testen. Die folgenden Artikel beschreiben nun die Probleme und deren Lösung, die mir und anderen Leuten bei der Umsetzung dieses Vorhabens begegnet sind.

MyODBC ist der Treiber für Zugriffe auf mySQL via ODBC. Auch MyODBC wird, wie mySQL, auf der mySQL-Website zum Download angeboten und es sind sowohl vorkompilierte Binärpackages als auch der Quellcode verfügbar.

Nach der Installation von MyODBC kann man im ODBC-Datenquellen-Manger von Windows den mySQL-Treiber beim Einrichten neuer ODBC-Datenquellen auswählen und damit eine Datenquelle einrichten, die auf eine mySQL-Server-Datenbank zeigt. Über eine solche Datenquelle kann man die mySQL-Tabellen nach MS Access verknüpfen.

MyODBC birgt einige Tücken, die erst nach einigem Rumprobieren und eingehendem Studium der verschiedenen Dokus und Readmes offenbar werden. Hier folgen ein paar Hinweise, wie man Probleme und Fehler vermeiden kann.

• Wenn man mySQL-Tabellen über MyODBC verknüpft, werden alle in diesem Moment eingestellten MyODBC-Optionen mit der eingebundenen Tabelle in Access gespeichert. Nachträgliche Änderungen an den Optionen der DSN haben keine Auswirkungen auf bereits eingebundene Tabellen. Man muss also die Tabellen erneut einbinden, wenn man die Optionen ändern möchte.
• Um mit MyODBC eine Datenquelle zu erstellen, die mit Access verwendet werden soll, sollte generell die Option Return matching rows aktiviert werden.
• BIGINT-Spalten in mySQL Tabellen sind generell problematisch, da Access den vollen Werteumfang von BIGINT (64Bit, d.h. bis 18446744073709551615) nicht unterstützt. Daher sollte man BIGINT-Spalten in eingebundenen Tabellen möglichst vermeiden.
  
  Die MyODBC-Option Change BIGINT Colums to INT kann nur begrenzt Abhilfe schaffen. Wenn diese Option aktiviert ist, ist es immerhin möglich BIGINT-Spalten zu verwenden, solange die enthaltenen Werte im Bereich des Access Datentyps 'Long Integer' liegen, Werte außerhalb dieses Bereichs werden falsch dargestellt und bei Aktualisierungen in Access falsch nach mySQL zurückgeschrieben.
  
  Als Primärschlüssel in eingebundenen Tabellen kann man BIGINT-Spalten generell nicht verwenden, da Access auch mit der aktivierten Change BIGINT Colums to INT-Option diese Spalten nicht als Primärschlüssel verarbeiten kann.
• Trace ODBC: Der MyODBC Treiber bietet selbst schon die Möglichkeit die ODBC-Aufrufe, die an die MySQL Datenbank geschickt werden, zu protokollieren. Gegenüber der Standardprotokollfunktion des Microsoft ODBC Data Source Administrators ist die Tracefunktion von MyODBC wesentlich performanter. Das erzeugte Protokoll ist zwar nicht ganz so ausführlich, sollte aber für die Bedürfnisse eines Access-Entwicklers bei weitem ausreichen.
• Access 2.0: Um MyODBC mit Access 2.0 zu verwenden, müssen generell die Optionen Simulate ODBC 1.0 und Return matching rows aktiviert werden. Sollten weiterhin Probleme auftreten, solltest du evtl., wie in Access 2.0 und MySQL beschrieben, versuchen eine alte 16bit Version von MyODBC zu verwenden.

In den MyODBC-Zip-Dateien befindet sich in der Regel eine Readme-Datei. Diese enthält aktuelle Informationen speziell zu der jeweiligen MyODBC Version. Auf der MySQL-Website gibt es im Manual noch ein paar weitere Informationen zu den MyODBC-Optionen.

Gelegentlich gibt es in verschiedenen Newsgroups Problemmeldungen mit bestimmten MyODBC-Versionen. Beim Einbinden von MySQL-Tabellen in Access Tritt z.B. folgede Fehlermeldung auf: "ODBC-Aufruf fehlgeschlagen -(TCX)(myODBC)You have an error in your SQL syntax near 'Datenbankname'.FROM 'Tabellenname' at line 1(#1064)".

Dies ist offenbar ein Bug in manchen speziellen MyODBC-Versionen (Z.B. bei der Version 2.50.33. trat das Problem auf). In der Regel lassen sich diese Probleme, ohne weitere Maßnahmen, mit einem Downgrade auf die vorige oder einem Upgrade auf die nächste MyODBC-Version beheben.

Du hast eine mySQL-Tabelle über ODBC in deine Access Datenbank eingebunden. Die Daten aus der mySQL-Tabelle werden auch angezeigt, aber du kannst in Access keine neuen Datensätze hinzufügen oder in den neuen Datensätzen steht nur '#Gelöscht'.

Die Ursache für das Problem liegt in den Feldern, die du beim Einbinden der Tabelle als eindeutiges Feld ausgewählt hast, oder in dem Primärschlüssel der mySQL Tabelle.

Access verwendet beim Schreiben in ODBC-Tabellen einen ODBC-Schlüsselgruppen-Cursor, der einen eindeutigen Primärschlüssel voraussetzt. Wenn beim Einbinden kein eindeutiges Feld ausgewählt wurde oder Access das Feld nicht als Primärschlüssel verwenden kann, treten die beschriebenen Problem auf. Namentlich die Datentypen CHAR, BIGINT und alle Fließkommatypen (REAL, FLOAT und DOUBLE) machen Access Probleme.

Diese Problematik wird auch in diesem Artikel in der Microsoft Knowledgebase beschrieben.

Du hast mySQL-Tabellen nach Access verknüpft, die Daten werden auch korrekt dargestellt, aber wenn du Daten in Access aktualisierst, erscheint häufig die Fehlermeldung "Schreibkonflikt - Dieser Datensatz wurde seit Beginn der Bearbeitung von einem andern Benutzer geändert", obwohl kein anderer Benutzer den Datensatz bearbeitet hat.

Dieses Problem tritt auf, wenn die eingegebenen Daten serverseitig von MySQL verändert werden. Das passiert z.B. in folgenden Fällen:

• Es wurde in einem neuen Datensatz keine Daten in ein Textfeld eingegeben, dass keine Nullwerte enthalten darf (NOT NULL bei der Tabellenerstellung), für das aber kein Default-Wert definiert wurde.
• Es wurde eine Eingabe in CHAR-Feld gemacht, die von mySQL bis zur angegebenen Feldlänge mit Leerzeichen aufgefüllt wurde.
• Es wurden Eingaben in ein Fließkomma-Feld gemacht, die von mySQL anders gerundet werden.

In diesen Fällen stellt Access zu Recht fest, dass der Datensatz von einem anderem Benutzer (nämlich der mySQL-DB selbst) geändert wurde.

Lösung: Du verwendest in allen mySQL Tabellen ein TIMESTAMP-Feld. Dann vergleicht Access beim Update der Daten nur noch den Primärschlüssel und das TIMESTAMP-Feld und stört sich nicht an den Änderungen, die mySQL an den Daten vornimmt.

Es gibt sicherlich noch weitere Situationen, die diesen Fehler auslösen, daher empfiehlt auch das mySQL-Manual in Tabellen, die über MyODBC verknüpft werden, generell ein TIMESTAMP-Feld einzufügen. Unabhängig von dieser konkreten Problematik, verbessert sich dadurch die Performance bei Tabellen mit vielen Spalten geringfügig.

Diese Problem konnte ich bisher selbst nicht nachvollziehen, allerdings wurde davon in den Access-Newsgroups berichtet.

Offenbar vergisst Access unter bestimmten Umständen die Einstellungen für Passwort und/oder Benutzernamen der mySQL Datenbank. Dieses Problem sollte man lösen können, indem man die mySQL-Tabellen beim Start der Access DB über eine VBA-Prozedur neu einbindet.

Ein Beispiel für eine solche Prozedur ist die folgende Sub.

Sub reconnectMySQL()

   Dim db    As DAO.Database

   Set db = CurrentDb()

   db.TableDefs("deineTabelle").Connect = _
        "ODBC;DSN=deineDSN;SERVER=deinServer;" & _
        "PORT=3306;OPTION=12345;" & _
        "DATABASE=deineDB;USER=deinUserName;" & _
        "PASSWORD=deinPasswort"
   db.TableDefs("deineTabelle").RefreshLink

   db.close
   Set db = Nothing

End Sub

Der Wert für OPTION definiert die MyODBC-Optionen die beim Zugriff auf die Daten verwendet werden, auch dann wenn im Setup der DSN andere Einstellungen eingetragen wurden.

Um herauszufinden, wie sich die Werte für OPTION errechnen und welchen du setzen musst, solltest du die Readme-Datei aus dem MyODBC-Zip-File lesen.

Der Zugriff auf eine mySQL Datenbank im Internet über ODBC ist im Prinzip ganz einfach und unterscheidet sich nicht von dem Zugriff auf eine DB im lokalen Netzwerk. Man sollte jedoch von vornherein bedenken, dass die Verbindungen ins Internet auch im Zeitalter von ISDN und Flatrate noch um ein Vielfaches langsamer sind, als in einem lokalem Firmennetz, daher ist es nicht empfehlenswert eine derartige Kombination als normale Produktionsapplikation zu verwenden. Um die Daten einer Website-Datenbank gelegentlich zu aktualisieren, kann dieses Verfahren durchaus brauchbar sein.

Die ODBC-Verbindung richtet man wie gewohnt ein, die Zugangsdaten, wie IP-Adresse, Portnummer, Datenbank- und Benutzname erhält man von seinem Provider.

Wenn es nicht möglich ist eine Verbindung zu der Datenbank im Internet herzustellen, liegt das häufig daran, dass einige Provider Zugriffe auf ihre mySQL Datenbanken nur von Hosts innerhalb ihres eigenen IP-Spaces zulassen und Zugriffe von fremden Rechner gundsätzlich abblocken. Um das zu testen, kann man versuchen mit den Tools mySQLManager oder mysqladmin, die man mit einer mySQL Distribution von der mySQL-Website herunterladen kann, eine Verbindung zur Datenbank aufzubauen. Wenn auch das nicht funktioniert, kann man davon ausgehen, dass es sich nicht um ein ODBC-Problem handelt.

Du hast eine Access Datenbank bestehend aus Frontend und Backend und möchtest jetzt das Backend auf einen mySQL-Server verlegen.

Bei cynergi.net gibt es ein fertiges Modul mit dem man sowohl die Tabellenstruktur als auch die Daten einer Access DB als SQL-Script für mySQL exportieren kann. Das Script kann man dann mit dem Tool mysql als Batch auf einem mySQL-Server ausführen lassen. Vorher sollte man jedoch, wie oben unter 'Grundloser Schreibkonflikt' beschrieben, ein TIMESTAMP-Feld zu jeder Tabelle hinzufügen.

Access 2.0 war die erste weit verbreitete Version von Microsoft Access. Obwohl Access 2.0 bald seinen 10. Geburtstag feiert (Erstveröffentlichung: 1. April 1994) wird diese Version von Access immer noch verwendet. Ich selbst habe mit Access 2.0 kaum praktisch gearbeitet, daher basieren diese Informationen auf Erfahrungen, die mir Besucher meiner Website mitgeteilt haben.

Im Gegensatz zu den späteren Versionen von Microsoft Access ist Access 2.0 eine 16-Bit-Anwendung, entwickelt für den Einsatz auf Microsoft Windows 3.1 und Windows NT 3.0. Aus diesen Grund hat Access 2.0 offenbar massive Probleme mit den heute gängigen 32-Bit-Versionen vom des MyODBC-Treibers für MySQL zusammenzuarbeiten. Die einfache Lösung für diese Probleme ist eine alte 16-Bit-Version von MyODBC zu verwenden. - Weniger einfach ist es allerdings diese alten MyODBC-Versionen zu finden. Auf der MySQL-Website ist der Downloadlink zu den alten Versionen offenbar nicht mehr vorhanden.
Ich habe hier auf dem FTP-Server ftp.fhh.opensource-mirror.de der Fachhochschule Hannover noch eine alte 16-Bit-Version von MyODBC gefunden.

Besonderer Dank gebührt in diesem Zusammenhang Kurt-Jürgen Schneider, der mich als erster auf die Lösung für diese Problematik aufmerksam gemacht hat.

Wie aus den anderen Artikeln auf dieser Seite schon recht deutlich hervorgeht, kann der traditionelle Zugriff auf MySQL über (My)ODBC und eingebundene Tabellen durchaus einige Probleme mit sich bringen. Für eine Anwendung, die MySQL als einziges Backend verwendet, führt meiner Meinung nach dennoch kein Weg daran vorbei. Wenn man MySQL jedoch nur als eine zusätzliche Datenquelle zu einem Access-Backend oder einem anderen Backend verwendet und nur gelegentlich oder nur wenige Daten aus der MySQL-Datenbank benötigt gibt es eine Alternative zum Zugriff über ODBC.

Grundsätzlich kann der Zugriff auf einen MySQL-Server auch über die Bibliothek libmysql.dll (bzw. die statische Bibliothek mysqlclient.lib) erfolgen. Diese Bibliothek ist eine C-DLL, die, genauso wie der MyODBC-Treiber, das proprietäre Kommunikationsprotokoll für den MySQL-Server kapselt und und nach außen "einfache" Funktionen für den Zugriff auf MySQL zu Verfügung stellt. Die Funktionen aus der lbmysql.dll kann man, wie die Funktionen anderer DLLs auch, über API-Deklarationen in VB(A) verfügbar machen und dort verwenden. Im Gegensatz zu der Verwendung des MyODBC-Treibers ist es nicht erforderlich die DLL zu installieren, sondern es reicht aus, wenn die DLL im System-Verzeichnis auf dem jeweiligen Rechner vorhanden ist (Xcopy Deployment). Außerdem entfällt dadurch der zusätzliche Overhead der ODBC-Schicht, die im MyODBC-Treiber die nativen Funktionen der mysqlclient.lib kapselt.

Eine ausführliche Dokumentation der C-API für MySQL ist im Kapitel "MySQL C API" in der Dokumentation zu MySQL enthalten. Online ist dieses Kapitel hier zu finden.

Es ist sicherlich nicht jedermanns Sache die kompletten API-Deklarationen selbst auszutüfteln. Zumal das zusätzlich noch einigen Aufwand mit sich bringt, wenn man in VB(A) noch eigene Wrapper-Funktionen für die API-Calls schreiben will. Wer diesen Aufwand nicht betreiben möchte, kann die von Eric Grau entwickelte ActiveX-DLL MyVbQL.dll verwenden, die weitgehend alle erforderlichen API-Funktionen aus der libmysql.dll kapselt und ihrerseits ActiveX-Objekte zur Verfügung stellt, die analog zu den ADO- und DAO-Recordset- bzw. -Connection-Objekten, für den Zugriff auf MySQL verwendet werden können. Die MyVbQL.dll ist inkl. des Sourcecodes hier zum Download erhältlich. - Allerdings sollte man sich gut überlegen, ob die Verwendung einer ActiveX-DLL wirklich dem MyODBC-Treiber vorzuziehen ist, da auch diese DLL installiert werden muss und in Access Probleme mit verloren Verweisen auf externe Bibliotheken verursachen kann. (Zu der Verweis-Thematik siehe den entsprechenden Artikel in der Access-FAQ von Karl Donaubauer.

Hinweis: Der Sourcecode der MyVbQL.dll ist öffentlich erhältlich und steht unter der LGPL. Das bedeutet, dass jeder den Sourcecode modifizieren und modifizierte Versionen der MyVbQL.dll unter der Voraussetzung vertreiben darf, dass er den kompletten Quellcode der modifizierten Version öffentlich verfügbar macht. Aber es beudetet auch, dass es nicht gestattet ist, den Quellcode der DLL in eine eigene Anwendung zu kopieren und diese zu vertreiben, sofern man nicht auch den kompletten Quellcode der eigenen Anwendung öffentlich verfügbar macht!

Ich möchte mich hier herzlich bei Klaus Oberdalhoff bedanken, der mich auf die MyVbQL.dll aufmerksam gemacht hat.

Wenn eine Access-Anwendung, in die über MyODBC MySQL-Tabellen eingebunden sind, eine Weile im Leerlauf war, d.h. die Anwendung war geöffnet, aber der Benutzer hat nicht damit gearbeitet, und dann nach dieser Ruhephase wieder mit der Anwendung gearbeitet wird, kommt es zu unerklärlichen Fehlern.

Je nach Access-Version treten verschiedene Fehler auf. Entweder stürzt Access komplett ab ("Microsoft Access hat ein Problem festgestellt und muss beendet werden.", meistens Access XP), oder es wird die Meldung "Dieser Vorgang wird den aktuellen Code in den Unterbrechungsmodus zurücksetzen." eingeblendet und danach können Formulare, Abfragen und Tabellen, die Daten aus MySQL darstellen, sowie das Access-Fenster überhaupt nicht mehr geschlossen werden, d.h. es passiert einfach gar nichts, wenn das jeweilige Fenster geschlossen werden soll (meistens Access 2000), oder jeglicher Zugriff auf MySQL-Daten wird mit einer Fehlermeldung á la "Sie haben die vorige Operation abgebrochen" quittiert (meistens Access 97).

Diese verschiedenen Symptome haben alle dieselbe Ursache. Die Jet-Engine schließt nach einer gewissen Zeit der Inaktivität die Verbindung zur ODBC-Datenquelle, also dem mySQL-Server, um die ungenutzten Ressourcen freizugeben. Eigentlich ein sinnvolles Feature, nur leider ist Access offenbar nach einem solchen Connection-Timeout nicht in der Lage die Verbindung wieder aufzubauen, wenn sie erneut benötigt wird. Stattdessen kommt es dann zu den oben beschriebenen Fehlermeldungen und Problemen.

Der Connetion-Timeout für ODBC-Vebindungen der Jet-Engine ist in der Windows-Registry, im dem Registry-Eintrag "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Jet\Version\Engines\ODBC\ConnectionTimeout" definiert (Anstelle von "Version" steht bei Access 97 "3.5" und bei späteren Access-/Jet-Versionen "4.0".).
Genau an dieser Stelle kann man auch mit einem Workaround ansetzen, um dieses Problem zu beheben. Entweder ändert man den dort eingetragenen Standardwert von 600 (Sekunden) auf einen Wert, der so groß ist, dass das Problem nur noch in Ausnahmefällen auftreten kann, oder man setzt den Wert in dem o.g. Registry-Eintrag auf 0. Damit wird der Connection-Timeout der Jet-Engine vollkommen deaktiviert. Damit tritt dieses Problem nicht mehr auf!

Du verwendest die Version 3.51.11 des MyODBC-Treibers und du verknüpfst Tabellen von MySQL nach Access, die Felder mit dem Datentyp Date oder DateTime enthalten. Diese Datumsfelder werden in Access aber nicht als Date-Felder erkannt, sondern als Felder mit dem Datentyp Text.

Bei diesem Problem handelt es sich um einen bestätigten Bug in der aktuellen Version 3.51.11-1 des MyODBC-Treibers (siehe MySQL-Bugreport). Die einzige Lösung für dieses Problem ist eine andere Version des MyODBC-Treibers zu installieren. Mögliche Alternativen sind entweder eine der vorhergehenden Versionen, oder die neuere BugFix-Version 3.51.11-2. Auf der offiziellen MyOBDC-Downloadseite ist bisher nur die fehlerhafte Version des MyODBC-Treibers verfügbar (Stand: 27. April 2005). Die neue, korrigierte Version gibt es bisher nur auf der Webseite von Peter Harvey (das ist der MySQL-AB-Mitarbeiter, der den Bug bearbeitet) unter folgendem URL http://www.peterharvey.org/Downloads/MySQL/MyODBC/.

Wenn du die fehlerhafte Version des Treibers durch eine andere ersetzt, musst du genau kontrollieren, dass die alte, defekte Version restlos deinstalliert wird. Am besten nach dem Deinstallieren manuell im Windows-Explorer überprüfen, dass auch alle alten Dateien entfernt wurden. Dazu im Windows\System32-Ordner nach den Dateien myodbc3.dll, myodbc3.lib und myodbc3d.dll suchen und, sofern sie dort noch vorhanden sind, diese Dateien manuell löschen. Erst danach die andere Version von MyODBC installieren.