Lies diesen Artikel und viele weitere mit einem kostenlosen, einwöchigen Testzugang.
Cloud-Computing bezeichnet die Bereitstellung von Rechenkapazität, Datenspeicher oder auch kompletten Anwendungen über das Internet. So bietet Microsoft beispielsweise eine spezielle Variante des SQL Servers namens SQL Azure an. Das ist für Access-Anwendungen interessant, deren Daten an mehreren Standorten verfügbar sein sollen oder wenn Außendienstmitarbeiter von unterwegs etwa auf Kundendaten zugreifen sollen. Wir schauen uns die Möglichkeiten von SQL Azure an und zeigen, wie Sie mit Access auf die enthaltenen Daten zugreifen.
Gestern und heute
Die Möglichkeiten des Zugriffs von Access auf Datenbanken im Internet fand lange Zeit gar nicht statt. Grundsätzlich geht es dabei darum, einen SQL Server auf einem Webserver zu betreiben, auf den man von Access aus beispielsweise via ODBC oder OLEDB zugreifen konnte. Aus Kostengründen kommt dabei, wenn überhaupt, MySQL zum Einsatz, das meist auf Linux-Servern läuft.
Mittlerweile bietet Microsoft zwei weitere Alternativen an: Die erste ist die Verwendung von SharePoint, auf die wir an anderer Stelle bereits eingingen (Online-Datenbanken mit Access und Sharepoint, www.access-im-unternehmen.de/632).
Dies soll nun mit Access 2010 weiter ausgebaut werden: Ein spezielles Datenbankformat soll auf einen SharePoint-Server übertragen und via Internet-Browser verwendet werden können. Dieses Datenbankformat kommt logischerweise mit einigen Einschränkungen bezüglich der Benutzeroberfläche und der Programmierung daher – so ist der Einsatz etwa von VBA nicht vorgesehen, stattdessen wurden die Möglichkeiten der Makro-Programmierung deutlich ausgebaut.
Grundsätzlich geht es aber gar nicht darum, Access-Anwendungen an sich ins Internet zu verschieben, sondern nur die referenzierten Daten beziehungsweise alles, was sich sonst im Backend einer Access-Datenbank befindet.
Und hier kommt der zweite Ansatz von Microsoft zur Geltung: die Cloud. Dort stellt Microsoft beispielsweise die Infrastruktur zur Verfügung, um eine SQL Server-Datenbank zu betreiben und auch über das Internet per ODBC-Verbindung darauf zuzugreifen.
Gegenüber der SharePoint-Variante, bei der die Datenbank per Internet-Browser gesteuert werden soll, bietet dies einige Vorteile: Sie brauchen beispielsweise auf keines der Elemente der gewohnten Benutzeroberfläche zu verzichten.
Und auch die Kostenfrage bei der Weitergabe einer solchen Anwendung ist schnell geklärt: Mit der Runtime-Version von Access können Sie Access-Anwendungen ohne Mehrkosten beliebig verteilen.
Schauen wir uns also an, wie wie eine Access-Datenbank in die Wolke hieven und wie diese anschließend funktioniert.
Voraussetzungen und Kosten
In der kleinsten Konfiguration einer ein maximal ein Gigabyte großen Datenbank kostet SQL Azure unter 10 Euro im Monat, hinzu kommen weitere Kosten für Traffic und Rechnerleistung. Eine Bezahlung ist nur per Kreditkarte möglich. Vielleicht besitzen Sie ein MSDN-Abonnement, dann können Sie bestimmte Dienste kostenlos nutzen – weitere Informationen finden Sie unter http://www.microsoft.com/online/help/de-de/helphowto/d459d51c-dddf-47ad-b488-2f59eb969b6d.htm.
Um sich für SQL Azure anzumelden, brauchen Sie ein Windows Live-Konto. Mit Ihrer Windows Live ID können Sie sich unter mocp.microsoftonline.com anmelden und dort ein Abonnement aufnehmen. Wir haben für die Tests in Zusammenhang dieses Beitrags den Dienst Windows Azure Platform – Nutzungstarif abonniert. Dazu wechsen Sie auf der Webseite zur Registerseite Dienste und stellen den Dienstfilter auf Windows Azure Platform ein (s. Bild 1). Das Abonnement kann laut Microsoft jederzeit gekündigt werden.
Bild 1: Anmelden für SQL Azure
Desweiteren benötigen Sie den SQL Server 2008 R2, auch die kostenlose Express-Version reicht aus: http://www.microsoft.com/express/Database/InstallOptions.aspx. Die SQL Server Database Engine enthält den benötigten ODBC-Treiber und mit dem SQL Server Managament Studio Express wandeln Sie eine bestehende Access-Datenbank in eine SQL Server-Datenbank um (sofern Sie nicht ohnehin bereits eine SQL Server-Datenbank besitzen, mit der Sie SQL Azure ausprobieren möchten).
Und jetzt
Nach der Anmeldung erhalten Sie eine E-Mail mit weiteren Hinweisen, die unter anderem einen Link zum Microsoft SQL Azure-Entwicklerportal enthält.
Dort finden Sie bereits eine Übersicht der Projekte, wo Sie bereits einen Eintrag mit dem zuvor vergebenen Namen vorfinden – es handelt sich hierbei um einen Datenbankserver (s. Bild 2).
Bild 2: Erste Schritte mit den Windows Azure Services
Nach dem Anklicken dieses Projekts müssen Sie noch die Nutzungsbedingungen lesen, aber dann geht es los: Als Erstes tragen Sie den Benutzernamen und das Kennwort des Administrators der neuen Datenbank ein. Beachten Sie die Hinweise für die Auswahl des Kennworts!
Damit ist die Erstellung des Datenbankservers abgeschlossen und Sie können bereits dessen Namen einsehen – diesen brauchen Sie später für das Einrichten der ODBC-Verbindung. Sie können nun ein neues Kennwort vergeben, den Server wieder löschen oder eine neue Datenbank anlegen (s. Bild 3).
Bild 3: Übersicht des neuen SQL Servers in der Wolke mit der Möglichkeit, eine neue Datenbank anzulegen.
Mit einem Mausklick auf Create Database erstellen Sie eine neue SQL Server-Datenbank. Im nun erscheinenden Dialog sollten Sie auf jeden Fall als Edition den Eintrag Web und als maximale Größe 1 GB auswählen, da dies die minimale und kostengünstigste Variante darstellt. Den Namen der Datenbank können Sie frei wählen, wir verwenden AiU.
Von Access zu SQL Server
Das Migrieren der Tabellen der Access-Datenbank zum SQL Server können wir hier aus Platzgründen nicht ausführlich beschreiben. Nach einem Mausklick auf den neuen Eintrag in der Liste der Datenbanken aktiviert die Webseite weitere Schaltflächen wie Connection Strings, Test Connectivity und Drop Database – mit letzterem können Sie die Datenbank wieder löschen.
Die Schaltfläche Connection Strings liefert Ihnen eine Vorlage für einen Connection-String, und Test Connectivity prüft den Zugriff auf die Datenbank. Dieser schlägt im ersten Anlauf fehl, wenn Sie nicht die Einstellungen der Firewall auf der Registerseite Firewall Settings bearbeitet haben.
Dort müssen Sie die Option Allow Microsoft Services access to this server aktivieren (s. Bild 4). Anschließend funktioniert auch der Verbindungsversuch von der Webseite aus.
Bild 4: Aktivieren der Firewall für die Microsoft Services
Das bedeutet allerdings noch lange nicht, dass dies auch vom heimischen Rechner aus gelingt: Sie müssen nämlich zusätzlich festlegen, von welcher IP die Firewall Anfragen an SQL Azure durchlassen soll.
Und wenn Sie wie nicht gerade in einem Unternehmen sitzen oder anderweitig mit einer festen IP zur Identifizierung verwenden, haben Sie ein kleines Problem: Die IP wird nämlich in der Regel zumindest einmal täglich neu zugewiesen, was das Festlegen der IP für die Firewall erschwert. Einige Service Provider wie T-Online haben überdies recht viele, große IP-Ranges, sodass eine Zuordnung hier Glücksache ist.
Die einfachste Möglichkeit, dennoch eine gültige Firewall-Einstellung zu verwenden, geht deutlich zu Lasten der Sicherheit: Dabei geben Sie einfach den vollen IP-Bereich frei und tragen unter IP Address Range die Grenzen 0.0.0.0 und 255.255.255.255 ein.
Nur für Testzwecke ist dies sicher in Ordnung, aber wenn Sie wichtige Daten in der Datenbank speichern möchten, sollten Sie sich entweder um eine feste IP kümmern, was beispielsweise für T-Online-Geschäftskunden mittlerweile kostenlos möglich sein soll.
Für die folgenden Schritte gehen wir davon aus, dass Sie die Firewall von SQL Azure so eingerichtet haben, dass der Zugriff funktioniert.
Eine Datenbank anlegen
Um eine kleine Testdatenbank mit einigen Tabellen anzulegen, verwenden Sie am besten das Microsoft SQL Server Management Studio, das in SQL Server 2008 R2 Express enthalten ist. Dort erscheint direkt beim Start der Anmeldedialog aus Bild 3 angezeigt wird (<Ihr Servername>.database.windows.net).
Bild 5: Anmeldung an SQL Azure vom Client aus
Dieser zeigt nach erfolgter Anmeldung genau das gleiche Bild wie nach dem Einrichten eines frischen SQL Servers auf einem lokalen Rechner an. Mit einem Klick auf den Eintrag Databases öffnen Sie die Liste der enthaltenen Datenbanken und stoßen gleich auf die bereits erstellte Datenbank (hier AiU). Wenn Sie auch diesen Eintrag durch einen Mausklick erweitern, finden Sie im Kontextmenü des Elements Tables den Befehl New Table…, mit dem Sie nun eine einfache Testtabelle einrichten können (s. Bild 6).
Bild 6: Mit diesem Eintrag legen Sie eine neue Tabelle im SQL Server an.
Sie finden dort ein SQL-Template vor, das Sie noch mit den Parametern der zu erstellenden Tabelle füllen müssen. Das SQL-Skript prüft zunächst, ob die zu erstellende Tabelle bereits vorhanden ist und löscht diese gegebenenfalls. Die folgende CREATE TABLE-Anweisung erstellt dann die neue Tabelle. Für eingefleischte Access-Entwickler gehören SQL-Statements allerdings nicht zu den Standardwerkzeugen zur Erstellung von Tabellen, hier wird eher den visuellen Techniken wie etwa der Tabellen-Entwurfsansicht gefrönt. Wir wenden uns also vom SQL Server Management Studio ab und verwenden schnell den SQL Server Migrations-Assistenten (SSMA), um Tabellen aus einer bestehenden Access-Datenbank zu unserer SQL Azure-Datenbank hinzuzufügen. Den SSMA finden Sie in der aktuellsten Version unter dem folgenden Link: http://www.microsoft.com/downloads/details.aspxFamilyID=5abe098d-c7e1-46c6-994a-09a2856eef0b&displaylang=en. Wählen Sie hier die Version für den SQL Server 2008 aus. Eine Beschreibung des Umgangs mit diesem Tool für die Version 2005 finden Sie im Beitrag Migration von Access zum SQL Server 2005 (www.access-im-unternehmen.de/490). Die Verwendung dieses Tools erfordert eine kurze Registrierung bei Microsoft, wofür Sie wiederum eine Microsoft Live ID benötigen. Im Gegenzug erhalten Sie eine Lizenzdatei, die Sie auf Ihrer Festplatte speichern und vor dem Start des SSMA auswählen müssen.
Die Migration sollte eigentlich ganz schnell gehen, aber bereits nach dem Auswählen der Quelldatenbank zeigte SSMA ein Ausrufezeichen mit dem Hinweis, dass eine Inkompatibilität zwischen SSMA und Datenzugriffskomponenten bestünde (siehe Bild 7). Die verwendete Konfiguration war Windows 7 64-bit mit Access 2010 32-bit. Offensichtlich wird der SSMA in diesem Fall auch als 64-bit-Version installiert, die aber mit den 32-bit-Komponenten für den Datenzugriff auf die Access-Datenbank nicht zurechtkommt.
Bild 7: Bei ungünstigen Kombinationen von Betriebssystem, SQL Server und Office-Version meckert der SSMA.
Eine Installation der 64-bit-Runtime von Access sollte Abhilfe schaffen, war aber auch nicht möglich, weil diese nicht parallel zur 32-bit-Version installiert werden konnte. Zum Glück gibt es jedoch virtuelle Maschinen, sodass die weiteren Experimente auf Windows 7 (32-bit) stattfanden (die Access-Version ist eigentlich unerheblich, da der SSMA auch mit Datenbanken klarkommen sollte, die mit älteren Access-Versionen erstellt wurden – und der nachfolgend beschriebene Zugriff via ODBC sollte auch mit älteren Versionen gelingen).
Mit einer reinen 32-bit-Konstellation klappt es nun (eine reine 64-bit-Variante sollte es auch tun): der Migration Wizard zeigt die Tabellen der Datenbank an und erlaubt die Auswahl der zu migrierenden Tabellen (s. Bild 8).
Ende des frei verfügbaren Teil. Wenn Du mehr lesen möchtest, hole Dir ...
Testzugang
eine Woche kostenlosen Zugriff auf diesen und mehr als 1.000 weitere Artikel
diesen und alle anderen Artikel mit dem Jahresabo