Ansprechpartner Datenbanken
Fachlicher Ansprechpartner:
Markus Schwienbacher (Dipl.-Inf. Univ)
Senior Manager
Tel.: (09 11) 98 89 - 0
Kundenbetreuung - Vertrieb:
Ralf Heumann
Leitung Key Account Management
Tel.: (09 11) 98 89 - 180
Postanschrift:
it innovations GmbHThomas-Mann-Str. 59
90471 Nürnberg
Diese E-Mail Adresse ist gegen Spam Bots geschützt, Sie müssen Javascript aktivieren, damit Sie sie sehen können
Trainer Login
Migration bestehender Access Datenbanken auf MS SQL Server
|
Diese Grafiken sollen veranschaulichen, wie sich die Datenhaltung bei einer Migration verändert.
Die Ziele einer Migration können unterschiedlich sein: 1. Datenbereitstellung für weiterführende/übergreifende Auswertung (Datawarehouse) Vorgehensweise bei einer Migration:
Es gibt folgende Migrations-Möglichkeiten für das Backend einer Access Anwendung: 1. Microsoft SQL Server Migration Assistant for Access (auch verfügbar für SQL Server 2008) 2. Upsizing-Assistenten von Access (in Access integriert) 3. Manuell Die beiden (1./2.) Assistenten unterscheiden sich wenig von der Interpretation der vorhandenen Access-Datenbankobjekten, jedoch bietet der Migrations-Assistent mehr Möglichkeiten die Struktur der neuen Tabellen auf dem SQL Server zu beeinflussen. Es ist zum Beispiel möglich die Datentypen der einzelnen Spalten explizit anzugeben. Nach der Ausführung des Assistenten sind Nacharbeiten bei den SQL Server Datenbankobjekten und in der Anwendung nötig. Diese resultieren aus Fehlinterpretationen der Access-Objekte, was in erster Linie auf die Art der Programmierung in Access zurück zuführen ist. Der Aufwand der Nacharbeiten ist je nach der gewählten Form der Migration unterschiedlich hoch. 1. Beibehaltung der.mdb, Verbindung der Datenbankobjekte über ODBCNacharbeit geringfügig, da nur die Tabellen migriert werden. Access-spezifische Syntax wird weiterhin unterstützt. 2. Migrieren in ein Access Database Project .adp, Verbindung der Datenbankobjekte über OLEDB .Aufwendigere Nacharbeiten, da alle Datenbankobjekte migriert werden. Access-spezifische Syntax wird nicht mehr unterstützt. Im Vorfeld ist es durchaus sinnvoll das Access-Projekt nach grundlegenden Fehlern zu durchforsten.Es sollte gewährleistet sein, dass die Datenbankobjekte den Regeln einer relationalen Datenbank entsprechen. So müssen alle Tabellen einen eindeutigen Schlüssel haben, Fremdschlüssel sollten auch als Beziehung (Relation) hinterlegt sein. Empfehlenswert ist auch eine Prüfung hinsichtlich der Normalisierung (= Basis für Relationen). Die Datenbank sollte sich in der dritten Normalform befinden.Ein typischer „Übersetzungs“-Fehler der Assistenten ist das Migrieren von „SELECT“-Statements mit „WHERE“ Anweisung als Funktionen. Da eine Funktion nur einen Parameter (kann auch eine Tabelle sein) zurück gibt ist es in den meisten Fällen sinnvoller hierfür eine Sicht oder eine Prozedur zu verwenden. Grundsätzlich sollte man alle von dem Assistenten angelegten Objekte überprüfen und den Sinn hinterfragen.
1. Bei ODBC hat man auch die Möglichkeit über sogenannte Passthrough-Abfragen Daten auszulesen. Diese Abfragen werden unter Umgehung der Jet-Engine direkt auf dem SQL Server ausgeführt. Hierfür muss T-SQL verwendet werden. 2. Bei OLEDB verwendet man RecordsetsDer Programmcode könnte wie folgt aussehen: Recordset bei Form_Load an das Formular binden Private Sub Form_Load() Set Me.Recordset = zfProcedureCall() End Sub Zugriff auf die Datenbank, erzeugen des Recordsets
1. SQL Server 2005, Microsoft Press ISBN: 3-86063-538-7Umfangreiches Nachschlagewerk zum Thema SQL Server |
|
|
|
|