MS Access wird gern als Prototyping-Werkzeug oder als Umgebung für die schnelle Entwicklung von Datenbankanwendungen unter Windows genutzt. Aber oft bleibt es nicht beim Prototyp und die schnell entwickelte Einzelplatzanwendung hat urplötzlich viele Nutzer. Wenn einem dann die Anwendung um die Ohren fliegt, erfährt man, dass Access keine solides Basis für skalierbare Anwendungen bietet.
Das gilt vor allem für die einer Access-Anwendung zugrunde liegenden Datentabellen, soweit sie in der
Jet-Engine verwaltet werden. Je größer die benötigten Tabellen, je mehr darauf zugreifende Nutzer, desto notwendiger wird ein Wechsel auf eine solide Datenbank.
Wenn es nach Microsoft ginge, führte der Upsizing-Pfad geradewegs zum SQL Server. Es gibt aber bessere Alternativen, die MS natürlich nicht mit einem Upsizing-Agenten (Extras/Datenbank Dienstprogramme) unterstützt. Trotzdem ist eine Migration der Daten nach DB2 mittels ODBC oder OLE DB eine einfache, gut automatisierbare Aufgabe. Die wesentlichen Schritte werden bestens in "
Migrating a Microsoft Access 2000 Database to IBM DB2 Universal Database 7.2" beschrieben. Auch wenn "2000" und "7.2" nicht gerade up-to-date klingt, es funktioniert auch mit aktuelleren Versionen.
Ich habe zum Exportieren meiner Access-Daten den Weg über das gute, alte ODBC gewählt. Das geht wie beschrieben recht einfach, bedeutet aber bei vielen Tabellen viel Klicken. Trotzdem lag noch der eine oder andere Stolperstein im Weg - als Anlass für folgende Ergänzungen zur o.a. Anleitung:
- Die Zieldatenbank muss vor dem Export der ersten Tabelle angelegt und als ODBC-Datenquelle registriert worden sein ("create database ..." und "catalog system odbc data source ..." in der Befehlszeile oder mit der Steuerzentrale und dem Kofiguration-Asistenten). Das ist offensichtlich kein wirklicher Stolperstein!
- Für die Aufnahme "breiter" Tabellen sollte man einen Tabellenbereich nebst Bufferpool mit hinreichender Seitengröße anlegen (z.B. mit "create bufferpool bufferpool8K immediate size 250 automatic pagesize 8 K" und "create large tablespace tbspace8K pagesize 8 K managed by automatic storage prefetchsize automatic bufferpool bufferpool8K").
- Für Tabellen mit vielen Zeilen reicht schon mal der voreingestellte Platz für das Transaktionsprotokoll nicht aus. Mit "update db cfg for <db> using logprimary <n> immediate", "update db cfg for <db> using logsecond <n> immediate" oder "update db cfg for <db> using logfilsiz <n> immediate" kann temporär oder ständig ausreichend Speicher für das Log zur Verfügung gestellt werden.
- DB2 mag keine Spaltennamen mit mehr als 30 Zeichen, Access dagegen bereitet das keinen Stress. Vor dem Export sollten also zu überlange Spaltennamen sinnvoll gekürzt werden, was in der Regel kein Problem darstellt.
- Bei einer Vielzahl von Tabellen wird der händische Export ein recht mühsames Unterfangen. Mittels eines Access-Makros kann der gesamte Prozess (teil-)automatisiert werden. Als Aktion wähle man "TransferDatenbank", als Transfertyp "Exportieren" und als Datenbankformat "ODBC-Datenbank". Leider müssen die Namen der Quell- und der Zieltabelle für jede zu transferierende Tabelle einzeln eingetippt werden. Der Prozess ist eben nur teilautomatisiert. Ein komfortabler Export aller Tabellen kann mit VBA-Programmierung erreicht werden.
Damit habe ich in die Zieldatenbank noch keine Indizes oder Integritätsbedingungen transferiert. Aber die Daten meiner Access-Anwendung befinden sich nun auf einer soliden, beliebig skalierbaren, perfomanten Basis.
ap127
Per Mausklicks, Makro oder VBA-Routine lassen sich in der Jet-Engine unter MS Access gespeicherte Tabellen wie beschrieben leicht nach DB2 migrieren. Eine Datenbank besteht aber nicht nur aus einer zusammenhanglosen Ansammlung von Tabellen. Die Access-Exp
Aufgenommen: Apr 09, 21:17
Was bisher geschah: Die Tabellen einer MS-Access-Anwendung sind zu groß geworden für die Jet-Engine. DB2 ist die Wahl der Stunde für die Datenhaltung als skalierbare, performate und vertrauenswürdige Basis. Tabellendefinitionen und Daten lassen sich
Aufgenommen: Apr 18, 11:10