Microsoft Access und SQLite eint auf den ersten Blick wenig. Hier das schwergewichtige Desktop-Datenbankmanagementsystem aus Redmond mit seiner grafischen Oberfl\u00e4che und den m\u00e4chtigen Formularen. Dort die winzige, serverlose Embedded-Datenbank, die in Milliarden von Ger\u00e4ten von Smartphones bis Webbrowsern ihr stilles Dasein fristet. Und doch werden die beiden Systeme immer wieder zusammengebracht \u2013 \u00fcber eine Technologie, die \u00e4lter ist als beide: ODBC.<\/p>\n\n\n\n
Bevor wir uns der Verbindungstechnik zuwenden, lohnt ein Blick auf das Wesen von Microsoft Access. In den Entwicklerforen von SQLite findet sich eine bemerkenswert pointierte Einsch\u00e4tzung: „Microsoft Access is NOT<\/strong> a database system“, schreibt dort ein Nutzer, und er hat nicht ganz unrecht. Access ist demnach ein „hooey-gooey“ \u2013 ein Werkzeug zur Erstellung grafischer Benutzeroberfl\u00e4chen, das \u00fcber ODBC mit eigentlichen Datenbanksystemen kommuniziert <\/a>.<\/p>\n\n\n\n Diese Sichtweise mag \u00fcberspitzt sein, trifft aber einen wunden Punkt: Access ist eine hybride Anwendung, die eine relationale Engine (standardm\u00e4\u00dfig das JET\/Access Database Engine) mit einem Rapid-Application-Development-Tool verbindet. Genau diese Hybrid-Natur macht es einerseits so flexibel, f\u00fchrt andererseits aber auch zu Verwirrung \u00fcber seine eigentliche Rolle <\/a>.<\/p>\n\n\n\n Die Verbindung zwischen Access und SQLite w\u00e4re ohne ODBC (Open Database Connectivity) undenkbar. ODBC ist ein offener Standard f\u00fcr eine Datenbankschnittstelle, der 1992 von Microsoft gemeinsam mit dem Unternehmen Simba entwickelt wurde. Der erste ODBC-Treiber, SIMBA.DLL, markierte damals den Beginn des standardisierten Datenzugriffs <\/a>.<\/p>\n\n\n\n Die Architektur ist bemerkenswert simpel und elegant: Eine Anwendung (hier Access) kommuniziert \u00fcber den ODBC-Treiber-Manager mit einem datenbankspezifischen Treiber. Der Treiber \u00fcbersetzt die Anfragen in das jeweilige Protokoll der Ziel-Datenbank. F\u00fcr die aufrufende Anwendung bleibt die Datenbank dahinter unsichtbar \u2013 sie spricht nur ODBC <\/a>.<\/p>\n\n\n\n Interessant ist die Entwicklungsgeschichte: Microsoft versuchte mehrfach, ODBC durch vermeintlich bessere Standards wie OLE DB und sp\u00e4ter ADO zu ersetzen. Doch ODBC erwies sich als z\u00e4hlebig. Es wurde zum De-facto-Standard f\u00fcr den SQL-Datenzugriff \u2013 unterst\u00fctzt von allen gro\u00dfen Datenbankherstellern wie Oracle und IBM, und heute plattform\u00fcbergreifend verf\u00fcgbar <\/a>.<\/p>\n\n\n\n Die Verbindung von Access zu SQLite erfordert einen spezifischen ODBC-Treiber f\u00fcr SQLite. Der wohl bekannteste freie Treiber stammt von der Website Entscheidend ist die Bit-Version: Access und der ODBC-Treiber m\u00fcssen in derselben Architektur vorliegen. Ein 64-Bit-Access kann nicht mit einem 32-Bit-ODBC-Treiber kommunizieren \u2013 eine Fehlerquelle, die immer wieder f\u00fcr Frustration sorgt <\/a>.<\/p>\n\n\n\n Im Access-Ribbon findet sich unter „Externe Daten“ die M\u00f6glichkeit, \u00fcber ODBC eine Verbindung herzustellen. Access bietet dann zwei grunds\u00e4tzlich verschiedene Vorgehensweisen <\/a>:<\/p>\n\n\n\nODBC: Der unsichtbare Vermittler<\/h3>\n\n\n\n
Der Treiber als Schl\u00fcssel<\/h3>\n\n\n\n
ch-werner.de<\/code> und wird auch in den SQLite-Foren empfohlen <\/a>. Kommerzielle Anbieter wie Devart bieten ebenfalls Treiber mit erweiterten Funktionen an <\/a>.<\/p>\n\n\n\nDie Verbindung: Zwei Wege f\u00fchren zum Ziel<\/h3>\n\n\n\n