SQL-Server Upsizer

8. Dezember 2013

Umwandlung einer Access- in eine SQL-Server-Datenbank

Im Laufe der Zeit haben wir eine Menge Datenbanken, die zunächst als reine Access-Anwendungen konzipiert waren, nicht zuletzt wegen der hier beschriebenen Vorteile auf einen SQL-Server portiert. Zum Einsatz kamen in diesem Zusammenhang bisher der » Microsoft SQL-Server und der Server » sqlAnywhere von Sybase. Zu diesem Zweck ist ein immer stärker verfeinerter Upsizer entstanden, der den Datenstand einer Access-Datenbank während der Entwicklung und zum Zeitpunkt der Umstellung auf den SQL-Server transportiert. Dabei bleiben alle wesentlichen Eigenschaften der Tabellenfelder wie Feldtypen, Default-Werte, Indizes, referentielle Integrität und zuletzt natürlich auch die Feldinhalte erhalten. Wir stellen den Upsizer hier der Internet-Gemeinde zur Verfügung (Download-Link oben rechts) und würden uns freuen, wenn er anderen Entwicklern Nutzen bringen sollte. Über etwaige Rückmeldungen im Kommentarbereich würden wir uns freuen. Sollten unüberwindliche Schwierigkeiten auftauschen, stehen wir natürlich auch gerne für Auskünfte zur Verfügung

Vorbereitung der zu transformierenden Datenbank

Die in diesem Abschnitt erwähnten Module LIB_DB und SQL_Portierung befinden sich in dem zum Download angebotenen Upsizer und können in jede andere Access-Datenbank importiert werden.

• Datumsfelder müssen sinnvolle Werte enthalten (nicht „01.01.199“ oder so).
• Tabellennamen dürfen nur maximal 30 Zeichen lang sein. (Diese Einschränkung gilt glaube ich nicht mehr. Trotzdem ist es sinnvoll, nicht zu lange Tabellennamen zu wählen.)
• Die Namen der Felder, Indexes etc. dürfen keine Umlaute und keine Sonderzeichen enthalten. (Auch dies stimmt wohl nicht mehr. Wir halten es aber trotzdem so, dass die Namen der SQL-Server-Objekte keine Umlaute und möglichst auch keine Leerzeichen enthalten.)
• Alle Tabellen brauchen einen Primary Key. Ansonsten können über die eingebundenen Tabellen keine Daten auf dem SQL-Server geändert werden.
• Eindeutige Indexes sind nur für solche Felder erlaubt, die immer <> NULL sind.
• Alle Indexes (auch die aus den Tabellenbeziehungen) gescheit benennen (wg. Wartbarkeit im Enterprise Manager).
  Geht z.B. folgendermaßen: Modul _LIB_DB in die Daten-MDB importieren. Mit DB_Relations_List() alle bestehenden Tabellenbeziehungen in zwei Tabellen _DB_Relations und _DB_Relations_Fields auflisten. In _DB_Relations trägt man die gewünschten Namen für die Beziehungen ein. Dann löscht man mit DB_Relations_Delete() alle Beziehungen aus der MDB und setzt mit DB_Relations_Set() die Beziehungen wieder, diesmal mit den neuen Namen.
• Eigenschaft “Required” für alle Felder prüfen. Required-Felder müssen immer Werte enthalten.
In Modul SQL_Portierung Fkt. RequiredCheck() prüft, für welche Felder mit „Required = Ja“ Datensätze ohne Eintrag existieren, die stehen dann hinterher in „/Required_Check()“. Mit RequiredSet() kann man nach „Befüllen“ der Tabelle „/Required“ für die gewünschten Felder „Required = Ja/Nein“ setzen.
• Prüfen, ob für alle Ja/Nein-Felder Standardwert eingetragen ist; ggf. ergänzen.
• Wenn eine Tabellenbeziehung von Tabelle X, Feld XF nach Tabelle Y, Feld YF besteht, so darf für YF kein Standardwert definiert sein.
• Wenn die Tabellenbeziehungen mit UpdateCasc und DelCasc zu kompliziert sind (zB. Beziehungen von TabA nach TabB, TabA nach TabC und TabB nach TabC), gibt es eventuell Probleme. Ggf. dann UpdateCasc und DelCasc herausnehmen und dies via Trigger implementieren.

Eingebundene Tabellen

Bevor es mit der eigentlichen Portierung losgeht, noch ein paar Anmerkungen zu eingebundenen Tabellen: Wenn eine Access-Anwendung so konzipiert ist, dass zu keinem Zeitpunkt die Inhalte großer Tabellen in Abfragen, Formulare oder Berichte geladen werden, kann man eine Access-Applikation im Prinzip ohne Veränderung auf dem SQL-Server weiter betreiben. Wir halten es so, dass wir beim Entwickeln von SQL-Server Applikationen zunächst einmal mit den Standard-Techniken eingebundene Tabellen und gebundene Formulare arbeiten. Nur wenn - aus welchen Gründen auch immer - Performance-Probleme auftreten, optimieren wir z.B. mit ODBC-Pass-Through-Abfragen, Stored Procedures oder Tabellenwertfunktionen. Man kann es unserer Erfahrung nach so formulieren: Nach der Portierung auf einen SQL-Server zeigen sich gnadenlos die konzeptionellen Schwächen einer Access-Anwendung. Gut geplante Anwendungen können demhingegen ohne große Änderungen von der Power des SQL-Servers profitieren.

Konzept des Programms

Es hat sich bei unseren Projekten bewährt, zunächst mit der ursprünglichen Access-Datenbank mit den Daten als Startpunkt für die Portierung auf den SQL-Server zu beginnen. Im Laufe der Arbeiten wurden aber jeweils Umbauarbeiten notwendig, so dass die gewünschte Zielstruktur für die erste SQL-Server-Datenbank nicht mehr genau der Ausgangsdatenbank entsprach. Diese mehr oder weniger stark modifizierte Datenbank mit der Zielstruktur nennen wir in unserem Upsizer Struktur-Datenbank. Der Upsizer versucht, diese Datenbank möglichst vollständig auf den SQL-Server zu übertragen.

Wenn der Zeitpunkt der Umstellung gekommen ist, wird die dann jeweils aktuelle Daten-Datenbank verwendet, um die frischen Daten in die SQL-Server-Datenbank zu übertragen. Die aktuelle Daten-Datenbank wird in unserem Upsizer Daten-Datenbank genannt.

Zusätzlich bestand in einem Projekt noch die Notwendigkeit, alte Daten aus einer anderen Datenbank in die SQL-Server-Datenbank zu übertragen. Um die Möglichkeiten des Upsizers zu illustrieren, haben wir den Link auf diese Alt-Datenbank in den Sourcen belassen. Er kann natürlich gelöscht werden.

Anpassungen des Upsizers

Natürlich steckt der Teufel auch bei einer SQL-Server-Portierung im Detail. Trotzdem sollte unser Upsizer dem Entwickler jede Menge Arbeit abnehmen. Um den Upsizer an die zu bewältigende Aufgabe anzupassen, müssen zunächst im Initialisierungsbereich des Moduls _Upsize der Pfad zu den Access-Datenbanken, deren Dateinamen sowie der Zugang zum SQL-Server eingetragen werden. Alle zu importierenden Tabellen werden danach in der Tabelle Tabellen vermerkt.

Sind diese Einstellungen vorgenommen worden, kann mit den ersten Testläufen begonnen werden, indem man das Makro Upsizer doppelklickt. Bei jeder zu konvertierenden Datenbank gibt es wieder neue Überraschungen, aber grundsätzlich sollte der Upsizer nach diesen Vorarbeiten funktionieren. Im Upsizer selbst gibt es für die Vor- und die Nacharbeiten beim Import noch die beiden Funktionen Upsize_PraeImport() und Upsize_PostImport(). 

Durchführung des Datentransfers

Ist der Tag der Entscheidung gekommen, kopiert man die dann frische Daten-MDB in das Verzeichnis mit den Access-Datenbanken, startet den Upsizer, der dann eine frische SQL-Server-Datenbank erzeugt, und liefert die SQL-Server-fähige Code-MDB aus - fertig.