Zur Hauptseite ... Zum Onlinearchiv ... Zum Abonnement ... Zum Newsletter ... Zu den Tools ... Zum Impressum ... Zum Login ...

Achtung: Dies ist nicht der vollständige Artikel, sondern nur ein paar Seiten davon. Wenn Sie hier nicht erfahren, was Sie wissen möchten, finden Sie am Ende Informationen darüber, wie Sie den ganzen Artikel lesen können.

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Gedrucktes Heft

Diesen Beitrag finden Sie in Ausgabe 1/2008.

Unser Angebot für Sie!

Lesen Sie diesen Beitrag und 500 andere sofort im Onlinearchiv, und erhalten Sie alle zwei Monate brandheißes Access-Know-how auf 72 gedruckten Seiten! Plus attraktive Präsente, zum Beispiel das bald erscheinende Buch 'Access 2010 - Das Grundlagenbuch für Entwickler'!

Diesen Beitrag twittern

Zusammenfassung

Lernen Sie Tipps und Tricks zum Einbinden von SQL Server-Tabellen in eine MDB kennen.

Techniken

Access, VBA, SQL

Voraussetzungen

SQL Server 2005, Access 2000-2007, VBA, SQL

Beispieldateien

Migration.mdb

Shortlink

548

Upsizing von Access nach SQL Server: Tabellen

Bernd Jungbluth, Horn

„Access ist eine Hausfrauen-Datenbank!“ - das ist eine oft und gern genutzte Phrase zur Verunglimpfung von Access-Datenbanken und ihren Entwicklern. Aber man kann diese Aussage auch positiv sehen und als Kompliment auffassen. Immerhin sorgt eine Hausfrau dafür, dass alles gepflegt und in Ordnung gehalten wird. Genau das macht Access auch. Es ist sehr tolerant und nimmt dem Entwickler viel Arbeit ab. Das ist bei einem größeren Datenbanksystem wie dem SQL Server bei Weitem nicht der Fall. Der SQL Server ist weitaus penibler und lässt dem Entwickler auch nicht allzu viel durchgehen. Hier muss der Entwickler selbst dafür sorgen, dass alles ordentlich ist und bleibt. Genau dieser Aspekt sorgt nach der Migration einer Access-Datenbank zu einer SQL Server-Datenbank immer wieder für Überraschungen. Das fängt schon mit den einfachsten Dingen an - den Tabellen.

Ob der Entwickler nach der Migration weiterhin von der Hausfrau unterstützt wird, hängt von der Art der Migration ab. Sofern Sie als Access-Applikation eine ADP verwenden, geht die Unterstützung verloren. Hier gibt es nur noch Access und SQL Server. Aber das ist eine andere Geschichte, über die wir noch berichten.

Arbeiten Sie nach der Migration mit einer MDB und eingebundenen Tabellen, steht Ihnen die Hausfrau weiterhin zu Seite, denn die Tabellen des SQL Servers werden in der MDB von der Jet-Engine - oder um beim Bild zu bleiben: von der Hausfrau - weiterverwaltet. Eine Access-Applikation mit eingebundenen Tabellen arbeitet mit zwei verschiedenen Datenbanken gleichzeitig: mit dem SQL Server und mit der Jet-Engine. Doch das irritiert eine Hausfrau nicht; um das bisschen Extra-Datenbank „SQL Server“ kümmert sie sich auch noch. In manchen Fällen aber nimmt es die Hausfrau etwas zu gründlich, was zu Fehlern führt beziehungsweise sich negativ auf die Performance auswirkt. Davon sind alle Objekte der Access-Applikation betroffen: eingebundene Tabellen, Abfragen, Formulare, Berichte und Module.

In diesem Beitrag lesen Sie, wie Access die eingebundenen Tabellen handhabt und was Sie dabei beachten müssen. Wenn hier vom „SQL-Server“ die Rede ist, dann ist der Microsoft SQL-Server gemeint. Der größte Teil der Ausführungen gilt allerdings auch für die Migration auf andere SQL-Server wie MySQL.

Tabellen

Wenn Sie sich nach der Migration auf den Microsoft SQL Server die neuen Server-Tabellen anschauen und diese mit den Access-Tabellen vergleichen, werden Sie einige Unterschiede in den Datentypen feststellen. Der SQL Server verwendet andere Datentypen als Access. Bei der Migration wurden die Access-Datentypen so gut es ging zu SQL Server-Datentypen migriert. Es gibt Datentypen in Access - wie den Hyperlink -, die es in SQL Server nicht gibt, das Gleiche gilt auch andersherum - den Datentyp XML gibt es so nur im SQL Server. In Tabelle 1 sehen Sie, wie die Access-Datentypen zu SQL Server-Datentypen migriert werden.

Dabei liefert die Migration nicht immer ein zufrieden stellendes Ergebnis. Der Access-Datentyp Ja/Nein wird als SQL Server-Datentyp bit mit deaktivierter Option NULL zulassen migriert. Grundsätzlich spricht nichts gegen die Migration in den Datentyp bit, aber die deaktivierte Option NULL zulassen ist in einigen Fällen arg übertrieben, da es das Speichern des Datensatzes ohne Angabe von Ja oder Nein verhindert. Um die Spalte leer lassen beziehungsweise Nullwerte zulassen zu können, muss die Option NULL zulassen manuell aktiviert werden.

Der Datentyp bit bietet noch eine weitere Besonderheit: Im Gegensatz zum Access-Datentyp Ja/Nein wird hier nicht Ja oder Nein beziehungsweise True oder False gespeichert, sondern lediglich 1 oder 0, wobei 1 für True beziehungsweise Ja und 0 für False beziehungsweise Nein steht. Diesen Umstand müssen Sie in Ihren Abfragen, Formularen, Berichten und Modulen berücksichtigen und diese gegebenenfalls anpassen.

Aber auch beim Einbinden der SQL Server-Tabellen in eine MDB sind die unterschiedlichen Datentypen ein wichtiger Punkt. Hier werden die Tabelleninformationen der SQL Server-Tabellen von der Jet-Engine übernommen und somit auch nur mit den Datentypen verwaltet, die die Jet-Engine kennt.

Tabelle 2 zeigt, wie welche SQL Server-Datentypen von der Jet-Engine umgesetzt werden.

Nicht nur in den SQL Server-Datentypen, sondern auch in den Eigenschaften der Datenspalten und der Tabellen nach der Migration einiges nicht mehr so aus wie unter Access oder ist einfach nicht mehr vorhanden.

So werden die Formatierungen von Datenfeldern durch Eigenschaften wie Format, Eingabeformat und Beschriftung, die mühsam in Access eingetragen wurden, nicht nach SQL Server migriert. Die Darstellung der Daten ist und bleibt Aufgabe des Clients; insofern gibt es im SQL Server für Formatierungen keine entsprechenden SQL-Befehle.

Eine weitere Art der Formatierung sind die seit Access 2000 verfügbaren Nachschlagefelder. Auch diese werden nicht nach SQL Server migriert. Die Nachschlagefelder fungieren wie ein Listenfeld. Zu dem in der Tabelle gespeicherten Fremdschlüssel werden die Beschreibungen aus der zugeordneten Tabelle gelesen und angezeigt. Ergo sind die Nachschlagefelder auch eine Art der Darstellung von Daten und fallen somit in das Ressort des Clients.

Keine Option für die Darstellung von Daten, aber trotzdem im SQL Server als solches nicht zu finden, ist die Eigenschaft Eingabe erforderlich. Diese verhindert das Anlegen beziehungsweise Ändern eines Datensatzes, wenn in der zugehörigen Spalte kein Wert erfasst wurde. Auch im SQL Server gibt es eine solche Eingabeprüfung, die Sie bereits kennen gelernt haben. Die Rede ist von der Option NULL zulassen. Ist diese aktiviert, darf die Spalte leer sein; ist sie nicht aktiviert, muss die Spalte einen Wert enthalten.

Für die ähnliche Eigenschaft Leere Zeichenfolge, die überwacht, ob in einer Spalte eine Zeichenkette von der Länge 0 eingegeben werden darf, gibt es kein Äquivalent wie bei Eingabe erforderlich. Diese Eigenschaft wird mit einer entsprechenden Check-Constraint-Anweisung (Feldbeschränkung) umgesetzt.

Apropos Check-Constraint: Diese in Access als Gültigkeitsregeln bekannten Prüfungen werden ebenfalls migriert - wenn auch nur die einfachen unter diesen Prüfungen. Enthält eine Access-Gültigkeitsregel Anweisungen beziehungsweise Funktionen, für die es in SQL Server kein Äquivalent gibt, wird die Gültigkeitsprüfung nicht migriert. Sofern Sie auf die Prüfung auch im SQL Server nicht verzichten können, müssen Sie den Check-Constraint manuell mit den Mitteln des SQL Servers anlegen. Das folgende Listing zeigt die Umsetzung eines Check-Constraints basierend auf der Access-Gültigkeitsprüfung <= Jetzt() mit dem zugehörigen Gültigkeitstext Das Datum muss in der Vergangenheit liegen:

ALTER TABLE [dbo].[CheckMich]

WITH CHECK ADD CONSTRAINT [CK_CheckMich Datum]

CHECK (([Datum]<getdate()))

GO

ALTER TABLE [dbo].[CheckMich] CHECK CONSTRAINT [CK_CheckMich Datum]

GO

EXEC sys.sp_addextendedproperty

@name=N'MS_ConstraintText',

@value=N'Das Datum muss in der Vergangenheit liegen.' , @level0type=N'SCHEMA',

@level0name=N'dbo',

@level1type=N'TABLE',

@level1name=N'CheckMich',

@level2type=N'CONSTRAINT',

@level2name=N'CK_CheckMich Datum'

Selbstverständlich werden bei einer Migration die Indizes einer Access-Tabelle zu SQL Server-Indizes migriert. In Tabelle 3 sehen Sie, wie die verschiedenen Möglichkeiten einer Index-Definition aus Access in SQL Server ankommen.

Bei dieser Gelegenheit eine Warnung: Sofern eine in Access indizierte Spalte NULL-Werte beinhaltet, wird nur die Struktur der Tabelle angelegt, aber keine Daten! Der SQL Server erwartet in einer indizierten Spalte Daten.

Der Primärschlüssel einer Access-Tabelle wird auch zu dem Primärschlüssel der entsprechenden SQL Server-Tabelle migriert. Dieser wird als eindeutiger, nicht gruppierter Index (nonclustered unique) angelegt. Sofern dieser Primärschlüssel im SQL Server als gruppierter Index (clustered) genutzt werden soll, muss dieser dort zunächst gelöscht und als solcher neu angelegt werden.

An dieser Stelle sei nur kurz erwähnt, dass der Primärschlüssel nicht zwangsläufig der gruppierte Index einer Tabelle sein muss. In manchen Fällen ist das sogar absolut unsinnig. Sofern eine Tabelle mehrere eindeutige Spalten besitzt, sollte diejenige Spalte als gruppierter Index genutzt werden, die am meisten für Tabellenverknüpfungen (Join), Sortierungen (Order) oder als Einschränkungskriterium (Where) genutzt wird.

So viel zu den Migrationsergebnissen und wo beziehungsweise wie Sie diese im SQL Server wiederfinden. Oder, besser gesagt, in Access, denn die SQL Server-Tabellen müssen noch in Access eingebunden werden, sofern dies nicht schon das Migrations-Tool für Sie erledigt hat.

Für das Einbinden von SQL Server-Tabellen in eine MDB benötigen Sie zunächst eine ODBC-Verbindung zu der entsprechenden SQL Server-Datenbank. Diese ODBC-Verbindung erstellen Sie entweder beim Einbinden der Tabellen über Datei|Externe Daten|Tabellen verknüpfen (in Access 2007 Externe Daten|Weitere|ODBC-Datenbank) oder vorab über Start|Systemsteuerung|

Verwaltung|Datenquellen (ODBC).

In beiden Fällen muss die ODBC-Verbindung auf dem Client eingerichtet und dort als DSN-Datei oder in der Registry gespeichert werden. Was natürlich einen erhöhten Wartungsaufwand erzeugt, da Sie sicherstellen müssen, dass auf jedem Client, der mit der migrierten Access-Applikation arbeitet, die entsprechenden DSN-Einträge vorhanden und korrekt konfiguriert sind.

Um diesen Verwaltungsaufwand zu sparen, können Sie die Tabellen auch beim Start der Applikation per VBA mit einer so genannten „DSNless-Connection“ einbinden.

DSNless bedeutet, dass für diese Art der Verbindung zur Datenquelle keine DSN-Datei verwaltet werden muss, sondern die Verbindung direkt über die ODBCAPI-Schnittstelle erzeugt wird, wobei die Verbindungsangaben in den Systemtabellen von Access gespeichert werden. Das folgende Listing zeigt eine solche Funktion:

Private Function TabellenEinbinden()

    On Error Resume Next

    Dim strODBC As String

    Dim tdfTable As DAO.TableDef

    strODBC = _

    "ODBC;DRIVER={SQL Server}; " _

    "SERVER=SQL2005;DATABASE=Northwind;" _

    & "Trusted_Connection=Yes"

    'oder bei SQL Server-Authentifizierung

    'strODBC = _

    ' "ODBC;DRIVER={SQL Server}; " _

    ' & "SERVER= SQL2005;DATABASE=Northwind;" _

    ' & "UID=user;PWD=password"

    Set tdfTable = CurrentDb. _

    CreateTableDef("Customers", 0&, _

    "dbo.Customers", strODBC)

    CurrentDb.TableDefs.Append tdfTable

    CurrentDb.TableDefs.Refresh

End Function

Wie bereits erwähnt, verwaltet die Jet-Engine die Tabellen des SQL Servers. Dazu speichert sie die Informationen über die Spalten und Indizes einer SQL Server-Tabelle in der MDB.

Sie haben das Ende des frei verfügbaren Teils des Artikels erreicht. Lesen Sie weiter, um zu erfahren, wie Sie den vollständigen Artikel lesen und auf viele hundert weitere Artikel zugreifen können.

Sind Sie Abonnent?Jetzt einloggen ...
 

Kompletten Artikel lesen?

Einfach für den Newsletter anmelden, dann lesen Sie schon in einer Minute den kompletten Artikel und erhalten die Beispieldatenbanken.

E-Mail:

Verwandte Beiträge:

Benutzerdefinierte Funktionen im MS SQL Server

Der DBMS-Connection-Wizard

Anmeldung an SQL Server und Co.

Gespeicherte Prozeduren

Datensicherung mit dem MS SQL Server

Trigger

DBMS-unabhängiger Zugriff auf SQL Server und Co.

Abfragen von Access zum SQL Server

Die Microsoft Data Engine (MSDE)

Von Access nach MySQL

© 2003-2015 André Minhorst Alle Rechte vorbehalten.