Der SQL Server für Windows CE
Veröffentlicht: 18. Nov 2001 | Aktualisiert : 16. Jun 2004
Von Paul Yao, David Durant
Mit dem SQL Server 2000 für Windows CE lassen sich mobile Geräte für Datenbankanwendungen einsetzen. Für den Abgleich mit einem stationären Datenbankserver stehen vielseitige Verbindungs- und Replikationsmechanismen zur Verfügung.
Auf dieser Seite
.gif){kind=icon}
Einsatzszenarien
Szenario 1: ein mobiler Handelsvertreter
Szenario 2: Lieferwagen
Szenario 3: Das drahtlose Kaufhaus
Szenario 4: Eine Registrierkasse
Szenario 5: Persönliche Datenbanken
Datenspeicherung in Windows CE
Die Architektur vom SQL Server CE
Die Vorbereitungen für den SQL Server CE
Datenmanipulation in Kurzform
Ein kurzer Blick auf die Verbindungen
Eine gute Verbindung ist alles
Die Arbeit mit den Daten
Der angebotene SQL-Umfang
Replikation
Zusammenführende Replikation
Szenario 1: Lesezugriff auf öffentliche Daten
Szenario 2: Lesezugriff auf private Daten
Szenario 3: Schreib-/Lesezugriff auf private Daten
RDA - Remote Data Access
SubmitSQL
Pull und Push
RDA oder zusammenführende Replikation?
Der Umgang mit Fehlern
Fazit
Diesen Artikel können Sie hier lesen dank freundlicher Unterstützung der Zeitschrift:
.gif)
Die letzten 50 Jahre haben einige deutliche Trends in der Entwicklung der Computerhardware aufgezeigt. So werden die Geräte zum Beispiel immer kleiner. Vor einem halben Jahrhundert gab es noch "Mainframes", die große Räume beanspruchten. In den sechziger Jahren wurden Minicomputer entwickelt, die trotz des Namens noch so groß wie Kühlschränke waren. Und in den Achtzigern breiteten sich in Windeseile Computer aus, die so groß wie ein mittlerer Hund waren. Heutzutage stellen winzige tragbare Telefone und PDAs (personal digital assistants) - Geräte, die in die Hosentasche passen - die aktuellen Meilensteine in der Saga von den unglaublich schrumpfenden Maschinen dar.
Inmitten solcher erstaunlicher Änderungen sind einige Dinge aber gleich geblieben. Computer haben in erster Linie die Aufgabe, in irgendeiner Form Daten zu verarbeiten, sei es nun in Form von Textdokumenten, Rechenblättern oder Datenbanken. Zur Bearbeitung der Daten braucht man Software und jede neue Hardware-Generation zieht neue Software nach sich, die versucht, die Leistungsfähigkeit der neuen Hardware auszuschöpfen. Zur Verbesserung der Datenverarbeitung auf mobilen Geräten, die Windows CE als Betriebssystem verwenden, hat Microsoft den SQL Server 2000 Windows CE Edition entwickelt (SQL Server CE). Tabelle T1 zeigt eine kleine Liste mit Windows CE-Geräten, auf denen man den SQL Server CE fahren kann.
T1 Auf diesen Geräten lässt sich der SQL Server CE benutzen.
Gerät |
Windows CE-Version |
H/PC Professional |
2.11 |
PCs in der Größe des Palm-PC |
2.11 |
Pocket PC |
3.0 |
HPC 2000 |
3.0 |
Eingebettete Geräte, die mit dem Platform Builder 3.0 entwickelt wurden. |
3.0 |
Um die Brauchbarkeit dieses Produkts abzuschätzen, empfiehlt sich ein Blick auf einige Einsatzszenarien, in denen die Stärken (und Schwächen) des Produkts deutlich werden. Für die Leser, die sich noch nicht mit Windows CE auskennen, werden wir kurz die Grundlagen der Datenspeicherung unter Windows CE beschreiben. Anschließend möchten wir Ihnen kurz die Werkzeuge vorstellen, die Sie für die Entwicklung von Programmen brauchen, die mit dem SQL Server Windows CE Edition arbeiten sollen. Außerdem werden wir auf die beiden Aspekte eingehen, die bei jedem Datenbankprodukt wichtig sind, das aus der Sicht des Anwenders "irgendwo im Hintergrund" läuft (also auf einer anderen Maschine): Die Datenmanipulation und die Verbindung zwischen dem zentralen Datenspeicher und dem fernen Anwender.
Die größte Herausforderung bei unserer Begegnung mit diesem Produkt war die richtige Konfiguration der beiden Verbindungsoptionen: Datenfernzugriff (RDA) und zusammenführende Replikation (Remote Data Access und merge replication). In unseren Schulungen, die wir zum Thema SQL Server bei Firmenkunden abhalten, stellen wir oft fest, dass die Datenbankprogrammierer nur geringe oder gar keine Erfahrung in der Entwicklung von Webanwendungen oder in der Konfiguration der Sicherheitsmechanismen haben - um nur die wichtigsten Punkte herauszugreifen. Aus diesem Grund möchten wir in der zweiten Hälfte dieses Artikels auf die kleinen Hürden zu sprechen kommen, die uns im Weg standen, und wie wir sie überwanden. Dabei möchten wir Ihnen auch einige Codebeispiele vorstellen, die Ihnen bei der Datenbankprogrammierung helfen sollen.
Im Folgenden werden wir den SQL Server 2000 Windows CE Edition kurz "SQL Server CE" nennen. Sofern nicht anders vermerkt, beziehen sich alle Referenzen auf den "SQL Server" auf die Versionen vom SQL Server, die unter Windows NT und 2000 laufen (SQL Server 6.5, SQL Server 7.0 und SQL Server 2000). Dabei handelt es sich um die Versionen vom SQL Server, die zum SQL Server CE kompatibel sind.
Einsatzszenarien
Drei Dinge kommen in allen der folgenden Szenarien vor: eine Maschine, die Windows CE fährt, ein paar Daten, die abgespeichert werden sollen, und ein Anwender, der wahrscheinlich, aber nicht notwendigerweise mobil ist. Zwei andere Elemente sind entscheidend: ein zentraler Datenspeicher, der von einer SQL Server-Datenbank verwaltet wird, und ein Transportmechanismus für die Übertragung der Daten zwischen der Windows CE-Maschine und der SQL Server-Datenbank.
Für die Datenübertragung bieten sich sehr viele Alternativen an, darunter welche mit einem richtigen Draht und andere, die ohne Drahtverbindung auskommen. Ein Windows CE-Gerät kann die Verbindung zur Außenwelt zum Beispiel mit den Favoriten vergangener Zeiten aufnehmen, wie Modems, herkömmlichen Netzwerken oder mit irgendwelchen Koppelstationen. Inzwischen gibt es aber auch noch andere Transportwege, darunter das Mobiltelefon, drahtlose Netze und Blue Tooth, die zwar noch nicht weit verbreitet sind, aber versprechen, sich zu besseren und schnelleren Wegen zur Datenübermittlung zu entwickeln.
Szenario 1: ein mobiler Handelsvertreter
Der Archetyp des Anwenders von mobilen Kommunikationsmitteln und Geräten ist der Handelsvertreter auf seiner Geschäftsreise. Man sagt, im Geschäft würde solange nichts geschehen, bis etwas verkauft wird. Wenn das stimmt, sollten wir alles unternehmen, um die Daten über die abgeschlossenen Geschäfte so schnell wie möglich einzuholen. Außerdem sollten wir auch die mobilen Handelsvertreter mit allen Daten versorgen, die sie brauchen, damit sie sich auf die Dinge konzentrieren können, die für ihre eigentliche Arbeit wichtig sind.
Da die meisten Handlungsreisenden nicht auf ihre Mobiltelefone verzichten möchten, bietet es sich an, eben dieses Mobiltelefon für den Datenaustausch zwischen dem Büro und dem mobilen Windows CE-Gerät zu benutzen. Natürlich könnte man das Windows CE-Gerät auch mit einem eigenen Mobiltelefon ausstatten. Zwischen den einzelnen Terminen spricht der Handelsvertreter wahrscheinlich via Mobiltelefon mit seinen Kunden. Gleichzeitig könnte das Windows CE-Gerät seine eigene Telefonverbindung mit dem Büro herstellen und neue Informationen von der Zentrale anfordern oder die Daten über die abgeschlossenen Geschäfte übermitteln.
Die Idee, den Computer mit seinem eigenen Telefon auszurüsten, mag auf den ersten Blick etwas seltsam erscheinen. Es ist aber nicht seltsamer als eine eigene Telefonleitung für das Modem des Desktop-Computers. Während ich diesen Artikel schreibe, haben viele Firmen schon Pocket-PCs in Planung, die mit einem eigenen Mobiltelefon ausgeliefert werden. Wir sind überzeugt, dass sich solche Geräte immer stärker durchsetzen werden und mehr und mehr Datenbankverbindungen auch via Mobiltelefon hergestellt werden.
Szenario 2: Lieferwagen
Es gibt natürlich auch Situationen, in denen der Informationsaustausch durchaus in größeren Abständen erfolgen kann. Oft reicht es aus, wenn die Daten einmal am Tag mit dem zentralen Datenspeicher abgeglichen werden. Stellen Sie sich einen ganz gewöhnlichen Lieferwagen vor - vielleicht für ganz alltägliche Güter wie Brot, Kekse oder Kartoffelchips - der die üblichen Bestellungen in der gewünschten Menge ausliefern soll. Sofern ein täglicher Abgleich der Bestell- und Lieferdaten ausreicht, könnte der Fahrer des Lieferwagens zum Beispiel das Windows CE-Gerät ins Büro bringen, sobald seine Schicht beginnt. Bei dieser Gelegenheit werden die Daten über die Lieferungen des Vortages heruntergeladen und die Lieferdaten für die neue Schicht auf das Windows CE-Gerät übertragen.
Das Grundprinzip ist dasselbe wie beim ersten Beispiel. Die Szenarien unterscheiden sich im Wesentlichen nur in der Häufigkeit der Verbindungsaufnahme zum zentralen Datenspeicher und in der verwendeten Übertragungstechnik. Wird das Gerät zum Beispiel zum Datenabgleich ins Büro gebracht, könnte die Verbindung zum SQL Server über eine normale Koppelstation oder über eine drahtlose Verbindung erfolgen. In beiden Fällen erfolgt die Verbindung via TCP/IP. Das Protokoll für den SQL Server CE ist HTTP (Sie müssen den SQL Server CE in der Version 1.1 oder höher fahren, damit ein typischer Pocket PC TCP/IP über die serielle oder die USB-Schnittstelle einsetzen kann (Siehe auch https://www.microsoft.com/sql/productinfo/ ceoverview.htm.).
Der Vorteil von HTTP als Protokoll liegt darin, dass es praktisch überall auf dieser Welt benutzt werden kann. Außerdem können Sie den Zugriff mit relativ geringem Aufwand in einer Weise einrichten, die zu den meisten Firewalls kompatibel ist. Im Kern steht dahinter derselbe Lösungsansatz, der in der neuen .NET-Architektur für die nächste Generation des Internets eingesetzt wird, nämlich für das "programmierbare Web".
Szenario 3: Das drahtlose Kaufhaus
Manche Geräte müssen nicht weltweit, sondern im Wesentlichen nur auf dem örtlichen Firmengelände mobil sein. Das gilt zum Beispiel für Strichcodeleser (von Firmen wie Intermec oder Symbol Technologies). Strichcodeleser werden üblicherweise in Kaufhäusern zur Erfassung des Bestands, der Aufträge und anderer Vorgänge benutzt, hinter denen die Aktualisierung der dazugehörigen Datenbanken steht. Häufig werden Strichcodeleser in einem drahtlosen RF-Netz eingesetzt. Das ermöglicht nach Bedarf die Datenübertragung zwischen dem zentralen Datenspeicher und den einzelnen Geräten.
Windows CE-Geräte lassen sich in solchen Szenarien auf verschiedene Weisen sinnvoll einsetzen. So könnten sie zum Beispiel für die Strichcodeleser als dumme Anzeigegeräte dienen, wobei die wichtigen Arbeiten von den zentralen Rechnern übernommen werden. Allerdings bringt dieser Lösungsansatz einige Probleme mit sich. So könnte das Netz von Zeit zu Zeit ausfallen. Vielleicht ist ein Gerät zu weit von den Sendern und Empfängern entfernt oder das Radiosignal vom Netz wird aus irgendwelchen Gründen blockiert. Als zweites Problem wird es gelegentlich zu Überlastungen der zentralen Server kommen, wenn in den Spitzenzeiten alle Geräte etwas von den Servern wollen.
In solch einer Umgebung bietet sich SQL Server CE als nahezu ideale Lösung an, denn der Strichcodeleser kann nun unabhängig vom restlichen System arbeiten, während der Anwender durch das Kaufhaus läuft. Alle erforderlichen Daten werden auf dem mobilen Gerät gespeichert, in einer SQL-Datenbank. In bestimmten Abständen wird die Datenbank auf dem portablen Windows CE-Gerät mit dem zentralen Datenspeicher synchronisiert, sofern sich eine Verbindung herstellen lässt und der Server verfügbar ist. Solch eine Konfiguration bietet ein Höchstmaß an Flexibilität, wobei die relevanten Datenbanken in akzeptablen Abständen aktualisiert werden.
Szenario 4: Eine Registrierkasse
Der SQL Server CE lässt sich auch dann sinnvoll einsetzen, wenn die Windows CE-Geräte gar nicht mobil sind. Stellen Sie sich eine Datenbank vor, die von einer kleinen Armee von Verkäufern über permanente Netzverbindungen benutzt wird. So könnte man zum Beispiel ein eine Registrierkasse mit Warenwirtschaftssystem implementieren - wobei die Geräte und die Netzverbindungen im Normalfall stets an Ort und Stelle bleiben. Bei solchen Geräten lohnt sich auch die Versorgung mit Netzstrom, denn bei ortsfesten Geräten bietet der teurere und umständlichere Batteriebetrieb kaum Vorteile. Vielleicht stehen die Terminals über eine große Verkaufsfläche verteilt, vielleicht in der Ladenkette einer Bäckerei oder eines Kaffeegeschäfts.
Verkaufsterminals sind darauf angewiesen, dass die zentralen Server die Arbeit übernehmen. Selbstverständlich können sich in der Praxis Probleme ergeben, angefangen beim Ausfall der Netzverbindung bis hin zu einer Überlastung der zentralen Server. Solche Ausfallzeiten sind gleichbedeutend mit einer einstweiligen Schließung des betreffenden Geschäfts. Um ein Höchstmaß an Zuverlässigkeit zu erreichen, ist es durchaus sinnvoll, jedes Kassenterminal möglichst eigenständig und unabhängig zu machen.
Durch die Installation des SQL Server CE erreichen Sie in solchen Szenarien die gewünschte Eigenständigkeit. Jedes Gerät kann einen Schnappschuss der Preisdatenbank erhalten. Anschließend können die Verkäufer die erforderlichen Buchungen auch dann vornehmen, wenn das Netz gerade ausgefallen ist oder die Zentralserver nicht verfügbar sind. Sobald sich Änderungen in der Preisdatenbank ergeben, können die neuen Preise in eine lokale Kopie der Preistabelle heruntergeladen werden, die auf dem Kassenterminal verfügbar ist.
Szenario 5: Persönliche Datenbanken
Bei allen bisher besprochenen Szenarien gab es eine Verbindung zu einem zentralen Server. Das ist sicher das wichtigste Szenario, für welches der SQL Server CE entwickelt wurde. Eine Datenbank lässt sich unter Windows CE aber auch ohne einen zentralen Datenspeicher verwalten. Stellen Sie sich zum Beispiel einen Handlungsreisenden vor, der Daten über die Restaurants erfasst, die er auf seiner Reise kennen lernt. Ihn interessiert vielleicht die Weinkarte, das Angebot an vegetarischen Menüs oder schlicht und ergreifend die Größe der Portionen. Die gesammelten Informationen fließen vielleicht in die Gestaltung der nächsten Reise ein, die ihn in dieselbe Gegend führt. Vielleicht reicht es sogar zu einer zweiten Karriere als Verfasser von Reisehandbüchern.
Der entscheidende Punkt ist, dass die lokale Restaurantdatenbank nirgendwo hoch- oder heruntergeladen wird, obwohl der Handlungsreisende natürlich seine primären Geschäftsinformationen weiterhin mit der zentralen Datenbank abgleicht. Die lokale Datenbank dient rein persönlichen Zwecken. Auch dafür lässt sich SQL Server CE einsetzen. Er bietet zwar nicht den gesamten Leistungsumfang der Serverversion an, aber SQL Server CE versteht die wichtigsten SQL-Befehle für die Erstellung und Aktualisierung einer Datenbank. Für eine eigenständige lokale Datenbank ist das mehr als ausreichend.
Datenspeicherung in Windows CE
Wenn Sie sich erstmals mit Windows CE beschäftigen, ist Ihnen vielleicht noch nicht geläufig, wie das Problem der Datenspeicherung gelöst wurde. Windows CE wurde für eine umfassende Palette von Plattformen konzipiert und kann mit einer entsprechend großen Anzahl an Speichergeräten umgehen. Ein Windows CE-Gerät könnte zum Beispiel so konfiguriert werden, dass es alle Geräte einsetzt, die auch in einem Desktop-PC verfügbar sind - Festplatten, Bandlaufwerke, DVD-Leser/Schreiber und so weiter, sofern die entsprechenden Gerätetreiber verfügbar sind. Die tatsächlichen Speichergeräte eines mobilen Windows CE-Geräts unterscheiden sich aber beträchtlich von dieser theoretischen Liste.
Stellen Sie sich einen Pocket-PC vor, zum Beispiel den HP Jornada 548. Ausgeliefert wurde er mit 16 MByte ROM, in dem das Betriebssystem liegt, und 32 MByte RAM für die Daten. Das ergibt insgesamt 48 MByte an Speicher. Um die Batterie zu schonen und das Gewicht auf ein Minimum zu drücken, hat ein typisches Windows CE-Gerät keine Festplatte.
Da eine Festplatte fehlt, richtet Windows CE einen speziellen Speicherbereich als Objektspeicher (object store) ein. Dieser Speicherbereich liegt im RAM und setzt sich aus drei Teilen zusammen: einem Dateisystem, einer Registrierdatenbank und den Windows CE-Datenbanken. Das Dateisystem kann dieselben langen Pfadangaben wie das Desktop-Windows verarbeiten. Ein Dateipfad kann also bis zu 260 Zeichen lang sein. Die hierarchische Registrierdatenbank ähnelt ihrem Gegenstück von den Desktop-Maschinen, obwohl die Registrierdatenbank von Windows CE in der Praxis natürlich wesentlich kleiner ist. Die Datenbankunterstützung beschränkt sich eher auf eine Art Manager für flache, einfache Dateien. Die eingebaute Datenbankunterstützung kommt etwas ungehobelt daher und der Zugriff neigt zur Zeitlupe, wenn Sie mit mehr als 1000 Datensätzen arbeiten. Man hat wohl eher an kleine Merkhilfen wie zum Beispiel ein persönliches Telefonbuch gedacht und nicht an ausgewachsene Datenbankanwendungen. Eine SQL Server CE-Datenbank liegt als Datei im Dateisystem des Windows CE-Geräts und greift in keiner Weise auf das zurück, was Windows CE als eingebaute Datenbankunterstützung zu bieten hat.
Da der Objektspeicher im RAM liegt, gibt es für den installierten RAM-Speicher des Geräts zwei grundsätzliche Einsatzgebiete: Programmspeicher oder Objektspeicher. Die Zuordnung zu diesen beiden Bereichen lässt sich entsprechend konfigurieren. Das kann entweder vom Programm aus geschehen oder in der Systemsteuerung. Der Platz im Objektspeicher wird durch einen minimalistischen Komprimierungsalgorithmus noch etwas gestreckt. Er ist zwar schnell, aber schwach und bietet eine magere Kompressionsrate von ungefähr 2:1, auf die Gesamtdaten im Objektspeicher gerechnet.
Erwähnenswert ist, dass die Windows CE-Datenbanken auf zwei verschiedene Weisen gespeichert werden können, nämlich an den Objektspeicher gebunden (mounted) oder ungebunden (unmounted). Wenn Sie trotz der Leistungseinbuße auf die Komprimierung im Objektspeicher zurückgreifen möchten, muss eine Windows CE-Datenbank als gebundene Datenbank gespeichert werden.
Wie viel Platz hat nun ein typischer Pocket-PC für die Datenbank? Teilt man die verfügbaren 32 MByte RAM in gleiche Teile auf, ergeben sich 16 MByte Programmspeicher und 16 MByte Objektspeicher. Berücksichtigt man die Komprimierung, erhält man zusätzliche 16 MByte für den Objektspeicher, der nun praktisch auf 32 MByte angewachsen ist.
In der heutigen Zeit, wo RAM eher in Hunderten von Megabytes gemessen wird und sich die gängigen Festplatten langsam den hundert Gigabyte nähern, scheint der Platz in einem Windows CE-Gerät relativ begrenzt zu sein. Allerdings können Sie den verfügbaren Speicherplatz durch installierbare Dateisysteme vergrößern (Dabei handelt es sich um reine Speichergeräte, also nicht um eine Erweiterung des verfügbaren Programmspeichers.). Ich habe auf meinem Pocket-PC einen CF-Steckplatz (Compact Flash), der dieselben Speicherkarten verträgt, die man in vielen Digitalkameras findet. Für ein paar Hundert Dollars kann ich den verfügbaren Speicherplatz um einige Hundert Megabyte erweitern (derzeit kann die größte CF-Speicherkarte, die wir gefunden haben, immerhin 256 MByte aufnehmen).
Es gibt sogar Festplatten, die in den CF-Steckplatz hineinpassen. IBM bietet eine 340-MByte-CF-Karte an und eine 1-GByte-CF-Karte, beide mit Festplatten ausgestattet. Ein wenig Ironie steckt schon darin, denn eigentlich wurden die mobilen Windows CE-Geräte ganz allgemein so konzipiert, dass es in ihnen keine rotierenden Medien gibt. Nun haben es die rotierenden Medien also geschafft, sich durch die Hintertür einzuschleichen, als CF-Speicherkarten maskiert.
Natürlich nicht ohne den entsprechenden Preis. Solch ein Laufwerk verbraucht ein wenig mehr Strom als eine CF-Karte, eben weil das Speichermedium gedreht werden will. Außerdem hat der Anwender wieder die allseits beliebte Qual der Wahl, den für ihn günstigsten Kompromiss aus Batterielebensdauer (oder Akku-Betriebszeit), Speicherkapazität und Kosten schließen zu dürfen (ein Megabyte auf der Festplatte ist etwas billiger als ein Megabyte auf einer herkömmlichen CF-Karte). Da sowohl die Speicherkarten als auch die Festplattenkarten ("spinning media cards") das FAT-System benutzen, ist zudem noch eine kleine Leistungsstrafe für die Umrechnung zwischen FAT und dem Dateisystem von Windows CE zu zahlen.
Eine SQL Server CE-Datenbank hat die Form einer Datei, die irgendwo dort liegen kann, wo Windows CE sie sieht. Das bedeutet natürlich, dass sie im Objektspeicher liegt, aber als reguläre Datei und nicht als Windows CE-Datenbank. Solch eine Datenbank kann auf jedem der installierbaren Dateisysteme oder Geräten liegen: Festplatten, CF-Speicherkarten oder sogar - sofern Sie die richtigen Gerätetreiber installiert haben - auf einem schreibfähigen CD- oder DVD-Laufwerk.
Jede SQL Server CE-Datenbank wird in Form einer einzigen eigenständigen Datei auf dem Gerät abgespeichert. Aus Sicherheitsgründen können Sie ein Kennwort für die Datei vorsehen und sie mit einem 128-Bit RSA-Algorithmus verschlüsseln. Dann muss Ihre Anwendung aber das Kennwort angeben, sobald sie Verbindung zur Datenbank aufnimmt. Als Endung für den Dateinamen wird .sdf empfohlen. Der Dateiname ist gleichzeitig auch der Name der Datenbank. Sie stellen also eine Verbindung zu mydb.sdf her, nicht zu mydb.
Die Architektur vom SQL Server CE
Wenn Sie den SQL Server CE fahren, wird er als Client vom SQL Server-Server angesehen (Tatsächlich handelt es sich beim SQL Server CE um eine DLL, die von OLE DB eingehüllt wird und im aufrufenden Prozess läuft, im Gegensatz zum SQL Server, der ein eigenständiger Server ist und außerhalb des aufrufenden Prozesses läuft.). Dieses Konzept zog einige wichtige Entscheidungen nach sich, die das SQL Server-Team bei der Implementierung berücksichtigen musste. So können zwei Geräte, die den SQL Server CE fahren, zum Beispiel nicht als Gleichgestellte (peer-to-peer) miteinander interagieren (Wer sich schon mit dem SQL Server von Windows NT und Windows 2000 beschäftigt hat, wird wissen, dass solche Interaktionen auf Peer-to-Peer-Basis beim SQL Server sehr wohl möglich sind.). Ein weiterer wichtiger Unterschied liegt darin, dass der SQL Server CE nur einen Anwender bedienen kann, wogegen der SQL Server selbstverständlich multiuserfähig ist.
Die meisten für den SQL Server CE entwickelten Anwendungen wird zwei Dinge beschäftigen: die Manipulation der Daten, während keine Verbindung zum Zentralserver besteht, und die Übertragung der Daten zum SQL Server nach dem Aufbau der Verbindung. Der erste Punkt ist ziemlich simpel und für jeden, der schon Anwendungen für den SQL Server geschrieben hat, ein geradezu "intuitiver" Vorgang. Der zweite Punkt, der Abgleich der Daten zwischen SQL Server und SQL Server CE, verlangt über die beteiligten Datenbanken hinaus nach den Internet Information Services (IIS). Datenbankprogrammierer und Administratoren werden vermutlich mit einer gewissen Begeisterung zur Kenntnis nehmen, dass die Datenmanipulation auf gewohnten Wegen erfolgt. Auf die Datenmanipulation im Windows CE-Gerät und auf die Datenübertragung werden wir später noch genauer eingehen. Zuvor erscheinen uns aber einige Worte zur Einführung angebracht zu sein.
Die Vorbereitungen für den SQL Server CE
Zur Entwicklung von Anwendungen für den SQL Server CE müssen Sie sich die SQL Server 2000 Developer Edition beschaffen, die eine Lizenz zum Herunterladen vom SQL Server CE enthält. Sobald Ihre Anwendung installationsbereit ist, brauchen Sie entweder die SQL Server 2000 Standard Edition oder die SQL Server 2000 Enterprise Edition.
Zum SQL Server CE gehören einige Beispielprogramme, die in eMbedded Visual Basic und eMbedded Visual C++ geschrieben wurden und sowohl RDA als auch die zusammenführende Replikation (merge replication) vorführen. Diese Beispiele sind ausgezeichnet und stellen sicherlich einen guten Ausgangspunkt für die Entwicklung von eigenen Anwendungen dar.
Wie alle Beispiele haben natürlich auch diese ihre Schwächen. So erwartet ein Teil des Codes zum Beispiel die Installation auf dem Laufwerk C. Falls sie den Code auf einem anderen Laufwerk installieren, müssen Sie ihn entsprechend abändern. Je nach der speziellen Umgebung, in der Sie arbeiten, wird auch eine Anpassung der Verbindungsstrings in den Beispielen erforderlich.
Wir haben die Beispiele für diesen Artikel mit eMbedded Visual Basic und ADOCE 3.1 geschrieben, weil diese Kombination unserer Ansicht nach den lesbarsten Code ergibt. Unser Beispielcode ist einfacher als die Beispiele vom SQL Server CE, weil wir uns auf bestimmte Aspekte der Anwendungsentwicklung konzentrieren und zudem großzügig die Fehlerbearbeitung weglassen, statt vollwertige Anwendungen vorzuführen.
Datenmanipulation in Kurzform
Die Bearbeitung der Daten in einer SQL Server CE-Datenbank ist ziemlich einfach, weil nur eine Programmkomponente im Spiel ist, und zwar entweder ein COM-Objekt (ADOCE) oder eine Programmierschnittstelle (OLEDBCE). Diese Komponenten entsprechen weitgehend ihren Desktop-Gegenstücken ADO und OLE DB. Wenn Sie schon mit ADO oder OLE DB vollständige Anwendungen entwickelt haben, dann brauchen Sie sich für den Zugriff auf den SQL Server CE kaum umzustellen. Die Programmierung für den SQL Server CE ist eher noch einfacher, weil als SQL-Sprache nur eine Teilmenge der SQL-Sprache vom SQL Server 2000 verfügbar ist ( Der SQL Server 2000 benutzt übrigens SQL-Konstrukte, die es beim SQL Server 6.5 und 7.0 nicht gibt.). So kennt der SQL Server CE zum Beispiel keine T-SQL-Grammatik.
Ein kurzer Blick auf die Verbindungen
Für den Datenaustausch zwischen SQL Server CE und SQL Server gibt es zwei separate Mechanismen, nämlich RDA und die zusammenführende Replikation (merge replication). Beide werden im Zusammenhang mit den IIS eingesetzt. Der komplizierteste Teil in der SQL Server CE-Anwendung ist im Allgemeinen die Datenübertragung zwischen SQL Server CE und SQL Server, insbesondere dann, wenn man noch nie mit der Replikation gearbeitet hat und auch noch keine IIS-Anwendungen entwickelt hat. Zu den Vorteilen von RDA und der zusammenführenden Replikation gehört, dass beide Verfahren nicht nur Daten bewegen, sondern auch die Schemata. Die Übertragung kann die gesamte Datenbank umfassen oder sich auf eine einzelne Tabelle beschränken. Die Kontrolle des Schemas liegt beim SQL Server. In den meisten Fällen kommen die SQL Server CE-Anwendungen daher ohne explizite Datendefinitionen aus.
Der Hauptvorteil vom RDA liegt im kleineren "Fußabdruck" im Speicher und in der etwas höheren Geschwindigkeit, die aus einem geringeren Funktionsumfang resultiert. Wichtigster Nachteil von RDA ist, dass dieser Mechanismus kaum zur Lösung von Konfliktfällen beiträgt. Bei der zusammenführenden Replikation (merge replication) ist es möglich, Regeln für die Aktualisierung der Datenbank aufzustellen, darunter natürlich auch Regeln zur Auflösung von Konflikten, die sich beim Überspielen neuer Daten in eine vorhandene Datenbank ergeben können. RDA ist auf allen Versionen vom SQL Server verfügbar, während es die zusammenführende Replikation nur mit dem SQL Server 2000 gibt. Tabelle T2 listet die Mechanismen zur Datenreplikation auf, die von den verschiedenen Versionen des SQL Servers angeboten werden. Unabhängig vom gewählten Datenübertragungsmechanismus bleibt das zugrundeliegende Netzprotokoll in beiden Fällen dasselbe: HTTP. Eine ISAP-Erweiterungs-DLL ist der einzige Weg, der SQL Server CE mit dem SQL Server verbindet.
T2 Die Mechanismen für den Datenabgleich
SQL Server-Version |
Remote Data Access |
Merge Replication |
SQL Server 6.5 |
ja |
|
SQL Server 7.0 |
ja |
|
SQL Server 2000 |
ja |
ja |
Es gab für das SQL Server CE-Team einige gute Gründe, den Weg über die IIS zu wählen. Ein bedeutender Teil der Anwender zählt zu den mobilen Anwendern. Daher müssen die Verbindungsoptionen auf einer möglichst breiten Basis stehen. Indem man die Verbindung des SQL Server CE via HTTP ermöglicht, kann im Prinzip jeder, der Zugriff auf eine Internet-Verbindung hat, auch auf die eigenen SQL Server-Datenbanken zugreifen. Neben der nahezu weltweiten Verfügbarkeit sorgt die IIS-Verbindung auch für die Authentifizierung und die Überprüfung der Autorisierung, damit die Daten des Anwenders die firmeneigene Firewall überwinden können. Und schließlich bieten die IIS auch noch ihre Fähigkeiten bei der Datenverschlüsselung an, sofern ein Zertifikat benutzt wird. Private Daten können also privat bleiben.
Wenn Daten zwischen SQL Server CE und SQL Server ausgetauscht werden, erhalten Sie die Datenkomprimierung sozusagen frei Haus. Die Daten werden für die Übertragung zwischen dem Windows CE-Gerät und der HTTP-Site, die als Empfänger dient, automatisch komprimiert. Bei einem kleinen Test mit der Northwind-Datenbank lag der Komprimierungsfaktor bei ungefähr 8:1. Während die Komprimierung immer eingeschaltet ist, gilt dies nicht für die Verschlüsselung. Allerdings können Sie die Verschlüsselung für die Daten einschalten, die zwischen SQL Server CE und dem Server übertragen werden, auf dem die IIS laufen, dank der kryptographischen Fähigkeiten der IIS. Da dies von den IIS geregelt wird, ist die Verschlüsselung für die beiden Datenbankmaschinen transparent.
Vielleicht sollten wir noch einmal darauf hinweisen, dass ein typischer Pocket-PC in einer Koppelstation mit einer seriellen (oder besser USB) Verbindung an den Computer angeschlossen ist, mit dem er verbunden wird. Wenn die Desktop-Verbindung als Stellvertreter (Proxy) für den HTTP-Auftrag dienen soll, sollten Sie wissen, dass Microsoft ActiveSync 3.1 dies nicht direkt anbietet. Der SQL Server CE 1.1 löst dieses Problem durch ein zusätzliches Stückchen Software, das die HTTP-Aufträge vom Desktop zum IIS-Server weiterleitet.
Eine gute Verbindung ist alles
Der schwierigste Punkt beim Einsatz des SQL Server CE ist der Verbindungsmechanismus. Der Mechanismus arbeitet etwas anders, als man auf den ersten Blick vermutet. So kann die Windows CE-Anwendung zum Beispiel keine direkte Verbindung zum SQL Server aufnehmen, weil es keine OLE DB-Treiber für solch eine direkte Kommunikation gibt. Ihre Anwendung muss die Übertragung der Daten zum SQL Server an den SQL Server CE delegieren.
Der SQL Server CE stellt keine direkte Verbindung zum SQL Server her. Statt dessen greift er via HTTP auf eine ISAPI-DLL-Datei namens sscesa10.dll zu, die über einen URL Ihrer Wahl verfügbar ist. Diese DLL stellt dann die Verbindung zum SQL Server her und sorgt für die Übertragung der Daten vom SQL Server CE an den SQL Server. Bei der Datenübermittlung vom SQL Server CE an den SQL Server sind Sie auf einen Vermittler angewiesen, nämlich auf die IIS. Das bedeutet, dass zwei Verbindungen hergestellt werden müssen, nämlich eine von Windows CE zur sscesa10.dll und eine von der sscesa10.dll zum SQL Server
.gif)
B1 Verbindungsaufnahme via IIS.
Wer sich schon mit den IIS auskennt, wird sicherlich wissen, dass sich die Verbindung vom Gerät zu den IIS in den Modi Anonymous, Basic Authentication oder Integrated Windows Authentication herstellen lässt. Die Verbindung von den IIS zum SQL Server lässt sich in den Modi Windows Authentication oder SQL Server Authentication herstellen. Daraus ergibt sich eine Verbindungs- und Sicherheitskette, die Ihre SQL Server CE-Anwendung umfasst, das Netz, das Betriebssystem, die IIS, NTFS, SQL Server und im Falle einer der Übertragungsmethoden auch ein gemeinsames Verzeichnis.
Allerdings sollten Sie die üblichen Fragen zur Installation klären, bevor Sie mit der Kodierung der Anwendung beginnen. Zum Beispiel, wo die DLLs liegen sollen, wo Sie den SQL Server finden und welche OS-Anwender Ausführungsrechte für die DLL und den SQL Server erhalten sollen.
Wie schon erwähnt, bieten die IIS drei Sicherheitskontexte an, von denen der SQL Server CE zwei benutzen kann (Basic und Integrated). Wenn Sie in einem Internet-Szenario die IIS und den SQL Server mit integrierter Sicherheit betreiben, müssen beide Server auf derselben Maschine laufen. Der Grund ist darin zu suchen, dass NTLM keine Sicherheitsbestätigungen (Security Credentials) über Maschinen hinweg vermittelt. Kerberos bietet das zwar unter Windows 2000 an, aber Windows CE kennt derzeit kein Kerberos. Wie bei jeder Webanwendung sollte bei der Basic Authentication mit dem Secure Sockets Layer (SSL) gearbeitet werden, damit Anwendername und Kennwort auf dem Gerät und der IIS-Maschine nicht entziffert werden können.
Die Arbeit mit den Daten
Der SQL Server CE beherrscht nur eine Teilmenge der Funktionalität des SQL Servers. Außerdem ist seine Datenbankmaschine kleiner. Um das zu erreichen, wurde ein Teil der Funktionalität weggelassen, zum Beispiel der SQL Admin-Dienst. Natürlich war dies unvermeidlich, denn in Windows CE gibt es in diesem Sinne keine Dienste. Außerdem gibt es keine Agenten, Jobs oder Zeitpläne, die es zu verwalten gilt. Da der SQL Server CE ein typisches Single-User-Produkt ist, gibt es auch keine Verknüpfungen zu anderen Servern. Und da die Sicherheit von einem Dateikennwort abhängt, gibt es keinen Bedarf für GRANT, DENY oder REVOKE. Außerdem fehlen die Transact-SQL-Erweiterungen vom SQL Server. Es gibt keine gespeicherten Prozeduren (stored procedures), keine Trigger, keine Batch-Läufe mit mehreren Anweisungen, kein DECLARE, SET, IF, WHILE, keine Stringfunktionen, keine numerischen Funktionen und keine parameterlosen Funktionen.
Die Datumsfunktionen gibt es allerdings im SQL Server CE. Selbst ein Teil des Standard-SQL wurde weggelassen. Es gibt keine Views oder UNIONs. Zudem lassen sich auch nicht alle Datentypen anwenden, die der SQL Server beherrscht. Die meisten dieser fehlenden Typen lassen sich aber in verfügbare Typen konvertieren. So bietet Windows CE zum Beispiel nur Unicode an. Daher sind nur die Unicode-Versionen der Zeichentypen verfügbar (wie NCHAR, NVARCHAR, NTEXT). SQL Server-Daten vom Typ CHAR werden bei der Übertragung auf den SQL Server CE nach NCHAR konvertiert. Falls Sie mit einer typischen ASCII-Lokalisation arbeiten (zum Beispiel Englisch), werden alle Texte und Zeichendaten, die natürlich als Unicode vorliegen müssen, nach ASCII komprimiert (UTF-8), um Platz zu sparen. Bei der Wahl von Unicode für den SQL Server CE war der Sachverhalt ausschlaggebend, dass dies auch der Standardzeichensatz vom Windows CE höchst selbst ist. Im Gegensatz zu Windows NT und 2000, die für die entsprechenden Win32-Funktionen ANSI- und Unicode-Versionen anbieten (wie MessageBoxA und MessageBoxW), sind unter Windows CE nur die Unicode-Versionen der Win32-Funktionen verfügbar (MessageBoxW).
Was der SQL Server CE bietet, ist seine Unterstützung für Tabellen, Indexe, Standardwerte und für die referentielle Integrität. Außerdem hat er die Fähigkeit, mit Hilfe der üblichen SQL Data Manipulation Language (DML) Zeilen (Datensätze) in diese Tabellen einzutragen, zu ändern und wieder zu löschen. Daher bearbeitet Ihre Anwendung die Daten im SQL Server CE, indem sie eine Verbindung zur Datenbank herstellt und ihr Befehle des Typs SELECT, INSERT, UPDATE und DELETE gibt. Oder sie öffnet einen Recordset und bearbeitet die Daten in der Ergebnismenge mit den verschiedenen Recordset-Methoden. Ihre SQL Server CE-Anwendung wird vielleicht etwas elementarer ausfallen, als Sie es von einer typischen SQL Server-Anwendung her gewohnt sind. Aber sie sollte genug Funktionalität mitbringen, um in den meisten mobilen Einsatzsituationen von Nutzen zu sein. Das Fehlen der vollständigen Transact-SQL-Syntax ist angesichts der in einem Windows CE-Gerät verfügbaren Speichermenge eine unvermeidliche Beschränkung. Trotz dieser Beschränkung dürfte der SQL Server CE aber für praktisch jede Windows CE-Anwendung, die Sie entwickeln werden, vermutlich eine mehr als ausreichende Menge an SQL-Befehlen bieten.
Für die Programmierung der Zugriffe auf die Datenbanken vom SQL Server CE gibt es zwei Objektmodelle, nämlich ADOCE und ADOXCE. Die ADOXCE-Objekte werden für DDL-Aktionen (database definition language) benutzt, wie die Erstellung, Änderung und Löschung von Datenbanken, Tabellen und Indizes. Aus drei Gründen möchten wir in diesem Artikel aber nicht näher auf ADOXCE eingehen. Erstens wurden ADOXCE-Objekte eher für die Wartung einer Datenbank konzipiert und nicht für die Datenmanipulation. Zweitens können Sie das Meiste von dem, was mit ADOXCE möglich ist, auch mit ADOCE erledigen. Drittens wird ein Großteil der Definition und Erstellung einer SQL Server CE-Datenbank via RDA oder Replikation erledigt. Wenn Sie an ADOXCE interessiert sind, finden Sie im SQL Server CE-Download einige Programmbeispiele.
Die ADOCE-Objekte werden von den Anwendungen zur Aufnahme der Verbindung zur SQL Server CE-Datenbank und zur Übermittlung und Bearbeitung von SQL-Befehlen benutzt. Wie der Name schon andeutet, orientiert sich dieses Modell am ADO-Objektmodell. Es enthält Objekte wie Connection und Recordset, mit Properties und Methoden wie MoveNext, EOF und Execute.
Der angebotene SQL-Umfang
Das Standard-SQL nach ANSI lässt sich in drei Teile aufteilen: DDL, DML und DCL (Data Control Language). ADOCE-Objekte werden normalerweise für den Einsatz folgender vier DML-Verben benutzt: SELECT, INSERT, UPDATE und DELETE. Allerdings können sie, wie schon erwähnt, auch zur Ausführung der folgenden drei DDL-Verben eingesetzt werden: CREATE, ALTER und DROP. Auf diese Weise kann ADOCE auch einen Großteil von dem tun, wofür ADOXCE da ist. Und die meisten Entwickler können sich auf ADOCE konzentrieren, ohne sich mit ADOXCE beschäftigen zu müssen. ADOCE lässt sich allerdings nicht zur Ausführung der folgenden drei DCL-Verben einsetzen: GRANT, DENY und REVOKE. Diese drei Verben gibt es im SQL Server CE nicht.
Zur Aufnahme einer Verbindung zur SQL Server CE-Datenbank braucht Ihre Anwendung ein Verbindungsobjekt und einen Verbindungsstring. Da zur Verbindungsaufnahme nur der Name des Anbieters (provider) und der Name der Datenbankdatei erforderlich sind, ist der Verbindungsstring ebenso einfach wie der Code. Ein Beispiel:
Dim refConn As ADOCE.Connection
Set refConn = CreateObject("ADOCE.Connection.3.1")
refConn.Open _
"Provider=Microsoft.SQL Server.OLEDB.CE.1.0; " & _
"Data Source=Northwind.sdf"
Sobald die Verbindung zur Datenbank steht, werden die erforderlichen Befehle an die Datenbank übermittelt. Der Code könnte so aussehen wie eines von den folgenden Beispielen:
refConn.Execute "DELETE Categories WHERE CategoryID = 3"
refConn.Execute "INSERT Categories " & _
"(CategoryName, Description) " & _
"VALUES ('Taco', 'Fast Food')"
refConn.Execute "CREATE TABLE MyTable (" & _
" PKCol int not null IDENTITY PRIMARY KEY, " & _
" AttrCol nvarchar(100) not null DEFAULT 'NA')"
Ein Recordset lässt sich auf folgende Weise erzeugen:
Dim refRS As ADOCE.Recordset
Set refRS = refConn.Execute("SELECT * FROM MyTable")
Auch die Schleife zur Bearbeitung dieses Recordsets ist ziemlich simpel:
Do Until refRS.EOF
Print refRS.Fields(0) & " : " & refRS.Fields(1)
refRS.MoveNext
Loop
Der Code schließlich, der die lästigen Aufräumarbeiten übernimmt, könnte so aussehen:
refRS.Close Set refRS = Nothing refConn.Close Set refConn = Nothing
Replikation
Wie schon erwähnt, übertragen die SQL Server CE-Anwendungen ihre Daten auf einem von zwei Wegen zwischen dem SQL Server und dem SQL Server CE, nämlich mit der zusammenführenden Replikation oder mit RDA. Der RDA-Mechanismus wurde so konzipiert, dass SQL Server CE auch mit älteren Versionen vom SQL Server zusammenarbeiten kann (genauer gesagt, mit den Versionen 6.5 und 7.0). Außerdem ist er auch für die Administratoren gedacht, die keine zusammenführende Replikation konfigurieren möchten.
RDA lässt sich leichter erklären, wenn die zusammenführende Replikation bereits bekannt ist. Also beginnen wir mit letzterer. Der SQL Server CE benutzt dabei den Replikationsmechanismus, den der SQL Server 2000 anbietet.
L1 Erste Synchronisation
' Deklariere das Replikationsobjekt für den SQL
' Server CE und lege es an.
Dim refRepl As SQL Server CE.Replication
Set refRepl = CreateObject("SQL Server CE.Replication.1.0")
' Internet-Verbindungsinfo - für die Verbindung vom
' Windows CE-Gerät zur ISAPI-DLL.
' Internetadresse der ISAPI-DLL.
' (IIS-Servername / virtuelles Verzeichnis / DLL-Name)
refRepl.InternetURL = "http://MyServer/Northwind/sscesa10.DLL"
' Name und Kennwort des Internet-Anwenders.
refRepl.InternetLogin = ""
refRepl.InternetPassword = ""
' Veröffentlicher-Infos (SQL Server) - für die
' Verbindung von der ISAPI-DLl zum SQL Server.
' Name des SQL Servers, auf dem die veröffentlichte
' Datenbank liegt.
refRepl.Publisher "MyServer"
' Name der veröffentlichten SQL Server-Datenbank.
refRepl.PublisherDatabase = "Nwind_SQLCE"
' Name der Veröffentlichung (Publication).
refRepl.Publication = "SQLCEReplDemo"
' Soll die Verbindung der DLL zum SQL Server mit
' Windows- oder mit SQL-Authentifizierung erfolgen?
refRepl.PublisherSecurityMode = NT_AUTHENTICATION
' Zur SQL-Authentifizierung müssen Anmeldename und
' Kennwort für den SQL Server angegeben werden.
refRepl.PublisherLogin = ""
refRepl.PublisherPassword = ""
' Abonnenten-Infos (SQL Server CE) - Infos über
' die Datenbank vom SQL Server CE.
' Verbindungsstring für die Datenbank vom SQL Server
' CE.
refRepl.SubscriberConnectionString = "data source=
orthwindRepl.sdf"
' Name des Abonnenten. Braucht nicht angegeben zu
' werden, wenn die Replikation auf dem SQL Server
' eingerichtet wird. Richten Sie die Replikation
' statt dessen für anonyme Abonnenten ein.
refRepl.Subscriber = "SQLCESubscr"
' Lege ein neues anonymes Abonnement an. Der Para-
' meter weist darauf hin, ob die SQL Server CE-Daten-
' bank bereits vorhanden ist oder noch angelegt wer-
' den muss.
refRepl.AddSubscription CREATE_DATABASE
' Führe die erste Synchronisation durch, damit der
' anfängliche Schnappschuss heruntergeladen wird. Zu
' diesem Zweck werden die Methoden Initialize, Run und
' Terminate aufgerufen.
refRepl.Initialize
refRepl.Run
refRepl.Terminate
Set refRepl = Nothing
Zusammenführende Replikation
Wer sich bereits mit der Replikation beschäftigt hat, wird wissen, wie wichtig eine gründliche Vorplanung und ein funktionsfähiges Konzept ist. Bei der ersten Begegnung mit der Replikation denken viele Leute noch, dass es ziemlich simpel ist, Datenbestände synchron zu halten, die an zwei verschiedenen Orten existieren. Aber schon die beiden folgenden Beispiele werden Ihnen einen Eindruck davon vermitteln, welche Komplikationen sich bei der Replikation ergeben können.
Im ersten Beispiel kommt ein Angebot des SQL Servers ins Spiel, das "Trigger" genannt wird. Eine Änderung in TableX führt automatisch dazu, dass in TableY eine Änderung eintritt. Der SQL Server CE kennt aber keine Trigger. Wenn TableX und TableY auf eine SQL Server CE-Datenbank repliziert werden, führt eine Änderung in TableX nicht mehr automatisch zu einer Änderung in TableY. Derselbe Befehl, der anscheinend auf dieselbe Tabelle angewendet wird, führt nun zu einem anderen Ergebnis. Und die Tabellen sind nicht mehr synchron. Daher ist es erforderlich, die Triggerlogik vom SQL Server im Code der SQL Server CE-Anwendung zu implementieren.
Ein weiteres Beispiel. Wenn Sie eine Tabelle replizieren, die einen Fremdschlüssel enthält, müssen Sie auch die Tabelle mit dem Primärschlüssel replizieren und die Zeilen validieren, die in die Tabelle mit dem Fremdschlüssel eingetragen werden. Vielleicht möchten Sie nur einen Teil der Zeilen aus der Tabelle mit dem Fremdschlüssel replizieren, zum Beispiel die Zeilen für die Delivery Route West92. Sie brauchen nur die Zeilen aus der Primärschlüsseltabelle (der Product-Tabelle) zu replizieren, die für die Delivery Route West92 wichtig sind. Aber der Code für die Auslieferungsroute ist keine Spalte der Product-Tabelle. Diese Operation lässt sich ausführen, indem man alle beteiligten Tabellen in den entsprechenden Beziehungen veröffentlicht, aber auch ein horizontales Filter einfügt, zum Beispiel durch Join-Filter für die Tabellen, die an der Veröffentlichungsdefinition beteiligt sind.
Nach diesen Vorüberlegungen werden auch die wichtigen Unterschiede verständlicher, die es zwischen der zusammenführenden Replikation und RDA gibt und erstere so attraktiv machen. Der RDA-Mechanismus ist zwar einfacher einzurichten, erfordert aber wesentlich mehr Code als die zusammenführende Replikation. Die zusammenführende Replikation macht es möglich, dass der Server einen großen Teil der Anwendungslogik kontrolliert, statt die Logik auf das Gerät zu verlagern. IDENTITY-Spalten mit bestimmten Wertebereichen und dynamische horizontale Partitionen sind zwei wichtige Beispiele für eine Logik, die im Server liegt und nicht auf dem Gerät. Dadurch lässt sich die auf dem Gerät erforderliche Codemenge beträchtlich reduzieren. Dieser Teil der Anwendung lässt sich zudem auf dem Server durchführen, statt auf dem Gerät.
Ein Replikationsschema will wohl geplant und gut vorbereitet sein. Das gilt auch für die Replikationen, die Sie mit den SQL Server CE-Anwendungen durchführen möchten. Daher möchten wir kurz die grundlegenden Konzepte für eine zusammenführende Replikation auf dem SQL Server erörtern.
Bei der zusammenführenden Replikation (merge replication), wie sie in einer SQL Server CE-Anwendung durchgeführt wird, wird der SQL Server als der Herausgeber (Publisher) bezeichnet, der eine oder mehr definierte Publikationen in einer oder mehr Datenbanken anzubieten hat. Die Datenbanken vom SQL Server CE sind die Abonnenten (Subscriber). Veröffentlichungen erfolgen in Form einer definierten Menge von Tabellen, Spalten und Filtern. Diese ausgewählten Tabellen werden als die Artikel einer Veröffentlichung bezeichnet (Articles of a Publication) und die Definition einer Teilmenge wie "nur columnA, columnB und columnC von TableX" oder "nur die Zeilen aus TableY, in denen der Routencode auf West92 lautet", werden Filter (filters) genannt. Mit Filtern ist es möglich, eine vertikale Teilmenge von einer Tabelle zu replizieren, wie das erste Beispiel aus dem vorigem Satz, oder eine horizontale Teilmenge einer Tabelle zu replizieren, wie im zweiten Beispiel, oder beides.
Abonnements (Subscriptions) haben direkt mit dem Konzept der Veröffentlichungen zu tun, wie es im SQL Server benutzt wird. Anwendungen, die mit eMbedded Visual Basic oder eMbedded Visual C++ entwickelt werden, richten solche Abonnements mit dem ActiveX-Steuerelement für den SQL Server CE ein, wobei sie dieselben Methoden und Properties benutzen, die bei der Verwaltung eines Abonnements für einen Merge-Client auf dem Desktop benutzt werden.
Listing L1 zeigt ein Codebeispiel für die erste Synchronisation. Der Code für eine erneute Synchronisation sieht so ähnlich aus und ist in Listing L2 zu sehen. Da die erste Synchronisation bereits durchgeführt wurde, ist der AddSubscription-Aufruf nicht mehr erforderlich. Die Objektpropertywerte sind dieselben wie in Listing L1. Allerdings wurde die Zahl der Komponenten reduziert, damit das Codebeispiel etwas kleiner wird.
Der Code aus den Listings L1 und L2 illustriert drei Punkte. Erstens sind zur Durchführung einer programmgesteuerten Replikation die Erstellung eines Objekts, die Änderung einiger Properties und der Aufruf von drei Methoden erforderlich, nämlich Initialize, Run und Terminate - wie auf dem Desktop. Zweitens lässt sich die SQL Server CE-Datenbank bei der Erstsynchronisation automatisch anlegen. Drittens bestimmen die bereits erwähnten Punkte zur Verbindungsaufnahme den Code der Anwendung (zum Beispiel die Konfiguration vom IIS-Server).
L2 Erneute Synchronisation
' Deklariere das Replikationsobjekt.
Dim refRepl As SSCE.Replication
' Lege das Replication-Objekt an.
Set refRepl = CreateObject("SSCE.Replication.1.0")
' Internet-Verbindungsinfos - die Informationen, die
' für die Verbindung vom Windows CE-Gerät zur ISAPI-
' DLL gebraucht werden.
refRepl.InternetURL = "http://MyServer/Northwind/sscesa10.dll"
refRepl.InternetLogin = ""
refRepl.InternetPassword = ""
' Veröffentlicher-Infos (SQL-Server) - die Informa-
' tionen für die Verbindung von der ISAPI-DLL zum
' SQL Server.
refRepl.Publisher = "MyServer"
refRepl.PublisherDatabase = "Nwind_SQLCE"
refRepl.Publication = "SQLCEReplDemo"
refRepl.PublisherSecurityMode = NT_AUTHENTICATION
refRepl.PublisherLogin = ""
refRepl.PublisherPassword = ""
' Abonnenten-Infos (SQL Server CE) - das sind die
' Informationen über die Datenbank vom SQL Server CE.
refRepl.SubscriberConnectionString = "data source=
orthwindRepl.sdf"
refRepl.Subscriber = "SQLCESubscr"
' Erneute Synchronisation des Abonnements, durch den
' Aufruf der Methoden Initialize, Run, Terminate.
refRepl.Initialize
refRepl.Run
refRepl.Terminate
Set refRepl = Nothing
Nun möchten wir uns etwas Zeit für die Besprechung der Verbindungsfragen nehmen und dann einige typische Anwendungsszenarien untersuchen. Allerdings haben wir nicht vor, hier die Beschreibungen aus den Books Online vom SQL Server CE zu wiederholen. Es geht uns eher um einen Überblick über die Verbindungskette von der SQL Server CE-Anwendung über die IIS bis hin zum SQL Server. Bei passender Gelegenheit werden wir auf die entsprechenden Einträge in den Books Online verweisen. Anschließend möchten wir uns die Implementierung der einzelnen Szenarien etwas genauer ansehen. Da sowohl die zusammenführende Replikation als auch der RDA-Mechanismus die Verbindung zum SQL Server mit Hilfe der sscesa10.dll herstellen, lässt sich praktisch alles, was wir im Folgenden besprechen, auch auf die RDA-Programmierung anwenden.
Damit die Verbindung vom SQL Server CE über die IIS zum SQL Server funktioniert, müssen Sie folgende Schritte ausführen:
Legen Sie auf dem Server, auf dem die IIS laufen, ein virtuelles Verzeichnis für die Anwendung an. Richten Sie das Installationsprogramm für die Seite des SQL Server CE so ein, dass es die Programmdateien in dem virtuellen Verzeichnis ablegt, das in den IIS angelegt wurde (siehe "Configuring IIS" in den SQL Server CE Books Online).
Falls es sie noch nicht gibt, tragen Sie für jede der Anwendungen die gewünschten Anwender und Gruppen im Betriebssystem ein (Verwenden Sie die dafür vorgesehenen Verwaltungsprogramme des Betriebssystems, zum Beispiel den User Manager for Domains in Windows NT. Normalerweise ist das die Aufgabe des Netzadministrators.).
Tragen Sie die Betriebssystemanwender und Gruppen als SQL Server-Anwender ein und geben Sie ihnen die erforderlichen Rechte für die Datenbank (Verwenden Sie dafür das entsprechende Verwaltungsprogramm, nämlich den SQL Server Enterprise Manager. Normalerweise ist das die Aufgabe des Administrators vom SQL Server.).
Wenn Sie mit der zusammenführenden Replikation (merge replication) arbeiten, starten Sie eine bestimmte gespeicherte Prozedur. Diese aktualisiert den SQL Server so, dass er mit dem SQL Server CE zusammenarbeiten kann.
In den zukünftigen Service Pack-Versionen vom SQL Server wird dieser Schritt nicht mehr erforderlich sein (Siehe "Updating SQL Server System Stored Procedures" in den SQL Server CE Books Online.).
Wenn Sie mit der zusammenführenden Replikation arbeiten, weisen Sie Leserechte auf das Verzeichnis zu, in dem die Schnappschussdateien gespeichert werden, damit die IIS Zugriff auf diese Dateien erhalten. Dieser Schritt ist aber nur erforderlich, wenn Sie NTFS benutzen. Für FAT(32) wird dieser Schritt nicht durchgeführt und lässt sich auch gar nicht durchführen (Die NTFS-Zugriffsrechte auf dieses Verzeichnis müssen in einem separaten Schritt vergeben werden.).
Wenn Sie die Datenübertragung mit der zusammenführenden Replikation erledigen, legen Sie die Veröffentlichungen des SQL Server an (Weitere Informationen finden Sie im Abschnitt "Creating the Publication" in den SQL Server CE Books Online unter https://msdn.microsoft.com/library/wcedoc/sqlce/replimplementing_3u3y.htm.).
Sehen wir uns nun einige typische Anwendungsszenarien und deren Implementierung an.
Szenario 1: Lesezugriff auf öffentliche Daten
Ihre Windows CE-Anwendung führt Lesezugriffe auf SQL Server-Daten durch, die von Haus aus öffentlich sind. Sie müssen für den allgemeinen Zugriff auf die Daten sorgen, brauchen diese Zugriffe aber nicht speziell zu verfolgen oder zu protokollieren.
Konfigurieren Sie die Properties vom virtuellen IIS-Verzeichnis so, dass mit dem Standardkonto IUSR_machine-name ein anonymer Zugriff möglich ist. Bild B2 zeigt, wie das unter Windows 2000 für die Northwind-Datenbank erledigt wird.
.gif)
B2 Hier wird der anonyme Zugriff gewährt.
Tragen Sie IUSR_machine-name für die SQL Server Windows Authenticated-Anmeldung ein und geben Sie ihm die Zugriffsrechte auf die Daten, die als öffentlich angesehen werden. Bild B3 zeigt, wie die Rechte im entsprechenden Eigenschaftsdialog vom SQL Server vergeben werden.
.gif)
B3 Hier wird der Zugriff auf die öffentlichen Daten gewährt.
Legen Sie im Code der Client-Anwendung den Windows-Authentifizierungsmodus für die Verbindung zwischen sscesa10.dll und SQL Server fest, indem Sie das Property PublisherSecurityMode auf NT_AUTHENTIFICATION setzen. Der dem Listing L2 entnommene Beispielcode für diesen Schritt sieht so aus:
Attribute VB_Name = "ReplWindowsAuth"
' Deklariere ein Replikationsobjekt für den SQL Server CE
' und lege es an.
Dim refRepl As SSCE.Replication
Set refRepl = CreateObject("SSCE.Replication.1.0")
...
' Weise die sscesa10.dll an, die Verbindung zum SQL Server
' mit Windows-Authentifizierung herzustellen.
refRepl.PublisherSecurityMode = NT_AUTHENTICATION
Sobald nun die Windows CE-Anwendung Verbindung zur DLL aufnimmt, läuft die DLL als IUSR_machine-name und nimmt auch als IUSR_machine-name Verbindung zum SQL Server auf. Dadurch erhält die Anwendung Zugang zu allen Daten, die für IUSR_machine-name angeboten werden, ohne spezielle Anmeldeinformationen für den SQL Server angeben zu müssen.
Szenario 2: Lesezugriff auf private Daten
In diesem Szenario hat Ihre Windows CE-Anwendung Lesezugriff auf SQL Server-Daten, die als private Daten der Anwendung gewertet werden. Sie möchten, dass zwar Ihre Anwendung Zugang zu diesen Daten hat, aber kein anderer Anwender - es sei denn, er benutzt dafür Ihre Anwendung.
Um das zu erreichen, richten Sie einen OS-Anwender oder eine passende Gruppe ein, die von der Anwendung für den Lesezugriff auf die Daten benutzt werden soll. Verwenden Sie dafür die üblichen Verwaltungsprogramme, mit denen man lokale Anwender und Gruppen definieren und verwalten kann (Unter Windows 2000 wählen Sie vom Startmenü aus Control Panel / Administrative Tools / Computer Management / Local Users and Groups. Unter Windows NT ist der Weg etwas kürzer: Start / Programs / Administrative Tools / User Manager for Domains.).
Konfigurieren Sie die Properties vom virtuellen IIS-Verzeichnis so, dass der anonyme Zugriff durch die vorgesehenen Anwender möglich ist. Bild B4 zeigt ein Beispiel. Tragen Sie dann die SQL Server Windows Authenticated-Anmeldung für den Anwender ein und geben Sie ihm Zugriff auf die Anwendungsdaten (auch hier möchten wir wieder auf Bild B3 verweisen).
.gif)
B4 Einrichtung des anonymen Zugriffs
Wie im vorigen Szenario kodieren Sie die Windows CE-Anwendung so, dass für die Verbindung zwischen sscesa10.dll und SQL Server der Windows-Authentifizierungsmodus benutzt wird. Zu diesem Zweck setzen Sie wieder das PublisherSecurityMode-Property auf NT_AUTHENTIFICATION.
Beide Szenarien stellen die Verbindung vom SQL Server CE zu den IIS mit anonymem Zugriff her. Das veranlasst die sscesa10.dll, als der angegebene Anwender zu laufen, unabhängig von den zusätzlichen Informationen, die von der Client-Anwendung zur Verfügung gestellt werden. Daher eignet sich die Identität des Anwenders, der die Client-Anwendung benutzt, nicht zur Steuerung des Zugriffs auf die SQL Server-Daten. Solange es nur um den Lesezugriff geht, mag diese Situation akzeptabel sein. Sobald die Daten aber von der Anwendung geändert werden dürfen, sollte man andere Regelungen treffen.
Szenario 3: Schreib-/Lesezugriff auf private Daten
Ihre Anwendung soll auf SQL Server-Daten zugreifen, die als private Daten betrachtet werden. Und sie soll diese Daten auch ändern dürfen. Außerdem soll es möglich sein, die Änderungen den Anwendern zuzuordnen (Vielleicht möchten Sie ja wissen, welche Lieferbestätigung zu welchem Fahrer gehört.).
Die Vorbereitungen im Betriebssystem liegen auf der Hand. Definieren Sie die entsprechenden Betriebssystemanwender, vielleicht für jeden Fahrer einen. Vielleicht definieren Sie auch für jede Anwendungsklasse eine Betriebssystemgruppe. Und schließlich tragen Sie die Anwender in die betreffenden Gruppen ein.
Etwas kniffliger wird schon die IIS-Sicherheitsseite der Gleichung. Zuerst konfigurieren Sie die Properties vom virtuellen IIS-Verzeichnis so, dass keine anonymen Zugriffe mehr möglich sind, sondern nur noch Zugriffe mit der integrierten Windows-Authentifizierung oder mit der Basisauthentifizierung. Die integrierte Windows-Authentifizierung, die sich am besten für Intranet-Anwendungen eignet, setzt Windows CE 3.0 voraus und eine sichere Netzumgebung. Die Basic Authentification eignet sich eher für Internet-Anwendungen, wo sie auch größeren Erfolg verspricht. Wenn Sie mit der integrierten Windows-Authentifizierung Probleme haben, versuchen Sie die Basic Authentification. Bild B5 zeigt, wie der Bildschirm bei der Einrichtung dieser Authentifizierungsart aussieht.
.gif)
B5 Basic Authentication.
Der letzte Schritt ist wie zuvor die Konfiguration des Zugriffs auf den SQL Server. Tragen Sie die Betriebssystemgruppe als SQL Server Windows Authenticated-Login ein und geben Sie ihr Zugriff auf die Daten der Anwendung.
Kodieren Sie die Anwendung auf dem Windows CE-Gerät so, dass sie für die Verbindung zwischen der sscesa10.dll und dem SQL Server den Windows-Authentifizierungsmodus benutzt. Und geben Sie den Sicherheitskontext an. Im Normalfall verwenden Sie den Betriebssystem-Anwendernamen und das Kennwort der Person, die mit der Anwendung arbeitet. Das ist die Identität, mit der die sscesa10.dll läuft. Diese Identität gilt auch für die Verbindung zum SQL Server. Listing L3 zeigt, wie der Code ungefähr aussieht, den Sie dafür schreiben müssen.
L3 Verbindung mit Windows-Authentifizierung
Attribute VB_Name = "ReplAppSpecify"
' Deklarieren Sie ein SQL Server CE-Replikations-
' objekt und legen Sie es an.
Dim refRepl As SSCE.Replication
Set refRepl = CreateObject("SSCE.Replication.1.0")
...
' Weisen Sie die sscesa10.dll an, die Verbindung zum
' SQL Server mit Windows-Authentifizierung herzu-
' stellen.
refRepl.PublisherSecurityMode = NT_AUTHENTICATION
...
' Internet-Anwendername und Kennwort. Das ist der
' Betriebssystemanwender, als welcher die DLL
' laufen soll.
refRepl.InternetLogin = "SFD00\ISAPIDLLTestUser"
refRepl.InternetPassword = "password"
Sie brauchen für den SQL Server nur einen Anmeldenamen anzugeben (er gehört zur Gruppe der Betriebssystemanwender). Das reicht aus, damit alle Betriebssystemanwender aus dieser Gruppe Verbindung zum SQL Server aufnehmen können. Obwohl nur der Gruppenname zur Anmeldung eingetragen wird, kann der SQL Server trotzdem die Aktivitäten der einzelnen Anwender aus dieser Gruppe verfolgen.
RDA - Remote Data Access
Die zweite Methode für den Datenaustausch zwischen SQL Server CE und SQL Server nennt sich, wie schon erwähnt, Remote Data Access. Obwohl RDA leichter einzurichten ist, erfordert es unter Umständen beträchtlich mehr Code, insbesondere dann, wenn die Funktionalität nachprogrammiert werden muss, die bei der zusammenführenden Replikation bereits von Haus aus verfügbar ist (zum Beispiel Identitätsspalten mit bestimmten Wertebereichen und dynamische horizontale Partitionen). Der wichtigste Vorteil dieses Mechanismus ist, dass ein SQL Server CE-Gerät damit auch zu älteren Versionen des SQL Servers Verbindung aufnehmen kann, nämlich zum SQL Server 6.5 und zum SQL Server 7.0. Eine zusammenführende Replikation bietet nur der SQL Server 2000 an. RDA erlaubt der SQL Server CE-Anwendung folgende Dinge:
Die direkte Änderung der SQL Server-Daten ohne vorherige Übertragung der Daten zum SQL Server CE.
Die Übertragung von Daten aus der SQL Server-Datenbank in eine SQL Server CE-Tabelle mit Hilfe der SELECT-Anweisung (Pull).
Die Übertragung von Daten aus einer SQL Server CE-Tabelle in die entsprechende SQL Server-Tabelle (Push).
Ein großer Teil der RDA-Programmierung für den SQL Server CE erfolgt an einem einzigen Programmierobjekt, nämlich am RDA-Objekt. Dieses Objekt hat drei Methoden, die in diesem Zusammenhang wichtig sind, nämlich SubmitSQL, Pull und Push. Außerdem hat es einige Properties, mit denen sich die Verbindungsinformationen angeben lassen und die bei der Bearbeitung von Fehlern helfen. So erwartet die Pull-Methode zum Beispiel die SELECT-Anweisung für den SQL Server, den Namen der Tabelle, die im SQL Server CE die Daten erhält, und den SQL Server-Verbindungsstring, alles als Parameter. Der Betriebssystem-Anwendername und das Kennwort müssen als Properties angegeben werden. Schauen wir uns die Methoden etwas genauer an.
SubmitSQL
Die Methode SubmitSQL umgeht den SQL Server CE vollständig und übermittelt einfach die SQL-Befehle, die keine Zeilen zur weiteren Bearbeitung im SQL Server liefern. So weist der Code in Listing L4 zum Beispiel die sscesa10.dll an, mit Windows-Authentifizierung eine Verbindung zur Northwind-Datenbank zu öffnen, die im SQL Server von SFD00 zu finden ist, und eine Zeile in die Tabelle Region aufzunehmen.
L4 Öffnung einer Verbindung.
' Lege ein RDA-Objekt an.
Dim refRDA As SSCE.RemoteDataAccess
Set refRDA = CreateObject("SSCE.RemoteDataAccess.1.0")
' Setze die Internet-Verbindungsproperties.
refRDA.InternetURL = "https://localhost/NorthWindRDA/sscesa10.dll"
refRDA.InternetLogin = "SFD00\ISAPIDLLTestUser"
refRDA.InternetPassword = "password"
' Übermittle den Befehl.
refRDA.SubmitSQL "INSERT INTO Region " & _
"VALUES(5, 'Central')", _
"Provider=SQLOLEDB.1;" & _
"Integrated Security=SSPI;" & _
"Persist Security Info=False;" & _
"Initial Catalog=Nwind_SQLCE;" & _
"Data Source=SFD00" _
' Aufräumen.
Set refRDA = Nothing
Wenn Sie bereits mit dem Objekt für die zusammenführende Replikation gearbeitet haben, kennen Sie vermutlich die InternetXxx-Properties: InternetURL, InternetLogin und InternetPassword. Neu ist der zweite Parameter von SubmitSQL, nämlich der Verbindungsstring. Wir werden ihn im Anschluss an die beiden anderen RDA-Methoden noch genauer untersuchen, die ebenfalls Verbindungsstringparameter haben.
Pull und Push
Die Methode Pull ähnelt SubmitSQL, denn sie übermittelt ebenfalls einen SQL-Befehl an den SQL Server. Allerdings muss dieser Befehl Zeilen liefern. Der Name einer SQL Server CE-Tabelle, die diese Zeilen aufnehmen soll, muss angegeben werden. Und die Tabelle darf noch nicht existieren.
Der Code aus Listing L5 holt zum Beispiel Informationen aus der Northwind-Tabelle Categories und legt sie in der Datenbank Northwind.sdf in einer Tabelle namens SQLCETargetTable ab.
L5 Pull
' Lege ein RDA-Objekt an.
Dim refRDA As SSCE.RemoteDataAccess
Set refRDA = CreateObject("SSCE.RemoteDataAccess.1.0")
' Lege die Properties für die Internetverbindung fest.
refRDA.InternetURL = "https://localhost/NorthWindRDA/sscesa10.DLL"
refRDA.InternetLogin = ""
refRDA.InternetPassword = ""
' Lege den Datenbankverbindungsstring für den
' SQL Server CE fest.
refRDA.LocalConnectionString = _
"Provider=Microsoft.SQLSERVER.OLEDB.CE.1.0;" & _
"Data Source=Northwind.sdf"
' Ziehe die Daten vom SQL Server zum SQL Server CE
' herüber. Die Zieltabelle darf noch nicht existieren.
refRDA.Pull "SQLCETargetTable", _
"SELECT CategoryID, CategoryName " & _
"FROM Categories", _
"Provider=SQLOLEDB.1;" & _
"Integrated Security=SSPI;" & _
"Persist Security Info=False;" & _
"Initial Catalog=Northwind;" & _
"Data Source=SFD00", _
TRACKINGON
' Aufräumen.
Set refRDA = Nothing
Zum besseren Verständnis der Push-Methode sollte man die Fähigkeiten des RDA-Mechanismus zur Erfassung von Änderungen kennen. So kann die Pull-Methode, wenn sie Datenzeilen vom SQL Server beschaffen soll, mit dem Parameter TRACKINGON aufgerufen werden. In diesem Fall werden alle nachfolgenden Änderungen an den gelieferten Zeilen erfasst. Wie bei der zusammenführenden Replikation erfordert dieser Track-Mechanismus, dass die gelieferte Tabelle zusätzliche Systeminformationen aufnimmt. Deswegen wird die neue SQL Server CE-Tabelle mehr Spalten haben, als in der SELECT-Anweisung erscheinen. Da die Pull-Methode die Zeilen in einer neuen Tabelle unterbringt und zudem noch jede Zeile mit Track-Informationen versehen wird, haben Sie nun eine SQL Server CE-Tabelle, deren Einträge sich auf ihre Quelltabellen im SQL Server zurückverfolgen lassen. Die Push-Methode ist darauf angewiesen, denn sie soll bei ihrem Aufruf alle Änderungen an die Datenbank vom SQL Server zurück übermitteln, die seit dem Pull-Vorgang aufgetreten sind.
Der Code aus Listing L6 lädt zum Beispiel alle Änderungen zum SQL Server hoch, die nach dem Pull an der SQL Server CE-Tabelle SQLCETargetTable vorgenommen wurden. Mit Ausnahme des Push statt des Pull ist er mit dem Code aus Listing L5 identisch.
L6 Push
' Lege ein RDA-Objekt an.
Dim refRDA As SSCE.RemoteDataAccess
Set refRDA = CreateObject("SSCE.RemoteDataAccess.1.0")
' Lege die Properties für die Internetverbindung fest.
refRDA.InternetURL = "https://localhost/NorthWindRDA/sscesa10.DLL"
refRDA.InternetLogin = ""
refRDA.InternetPassword = ""
' Lege den Datenbankverbindungsstring für den
' SQL Server CE fest.
refRDA.LocalConnectionString = _
"Provider=Microsoft.SQLSERVER.OLEDB.CE.1.0;" & _
"Data Source=Northwind.sdf"a
' Schiebe die Änderungen zum SQL Server hinüber.
refRDA.Push "SQLCETargetTable", _
"Provider=SQLOLEDB.1;" & _
"Integrated Security=SSPI;" & _
"Persist Security Info=False;" & _
"Initial Catalog=Northwind;" & _
"Data Source=SFD00"
' Aufräumen.
Set refRDA = Nothing
Alle drei RDA-Methoden haben einen Verbindungsstringparameter. Dabei handelt es sich um denselben Verbindungsstring, den jede Client-Anwendung für den SQL Server angeben muss. Er gibt den Namen des Anbieters an, den Verbindungsmodus, den Servernamen, den Datenbanknamen und bei Bedarf auch den Anmeldenamen und das Kennwort. Die meisten Entwicklungsumgebungen wie zum Beispiel Visual Basic 6.0, in denen man Clients für den SQL Server entwickeln kann, bieten auch Werkzeuge an, die den Verbindungsstring für Sie generieren. Auf diese Weise lassen sich sehr leicht Beispielstrings generieren, mit deren Hilfe man auch leicht die Syntax für die Anbieter lernen kann.
Das Vorkommen dieses Parameters in allen drei RDA-Methoden bekräftigt noch einmal die verbindungslose Arbeit des SQL Server CE. Der Verbindungsstring für den SQL Server muss bei allen Methoden angegeben werden, damit sie die Verbindung herstellen, die geplante Operation durchführen und die Verbindung dann wieder trennen können. Alle Änderungen, die zwischen einem Pull und einem Push in der SQL Server CE-Datenbank erfolgen, werden durchgeführt, ohne dass eine Verbindung zum SQL Server besteht.
RDA oder zusammenführende Replikation?
Eine wichtige Entwurfsentscheidung für die geplante Anwendung ist die Wahl des Übertragungsmechanismus. Wenn Sie mit dem SQL Server 6.5 oder 7.0 arbeiten müssen, ist der Würfel allerdings schon gefallen. Sie müssen zu RDA greifen, weil die zusammenführende Replikation einfach nicht angeboten wird. Beim SQL Server 2000 bleibt Ihnen dagegen die Qual der Wahl erhalten. Sie können beide Mechanismen einsetzen.
Der größte Unterschied liegt darin, dass es bei der zusammenführenden Replikation möglich ist, die Beziehungen zwischen den Desktop-Daten und den SQL Server CE-Daten deklarativ anzugeben, durch die Definition von "Veröffentlichungen" (publications), während man beim RDA SQL-Code schreiben muss, in dem die zu übertragenden Daten festgelegt werden. Daher übernimmt bei der zusammenführenden Replikation die zentrale Datenbank die Kontrolle über die Datenbewegung, während beim RDA das Windows CE-Gerät das Sagen hat.
Anfangs sieht es deswegen vielleicht so aus, als sei RDA die bessere Wahl. Sie schreiben einfach eine SELECT-Anweisung, rufen die PULL-Methode auf und der SQL Server CE legt eine Tabelle an und sorgt für die Übertragung der ausgewählten Daten in die Tabelle. Kein Grund, sich mit der Konfiguration der Replikation herumzuschlagen.
Nun, für eine einmalige Anwendung oder für ein einfaches Programm mag das richtig sein. Für eine größere Anwendung empfiehlt sich aber die zusammenführende Replikation, weil sie Leistungen bietet, bei denen RDA nicht mithalten kann. Die Auflösung von Konflikten, von denen bereits die Rede war, ist einer dieser Punkte. Ein weiterer sind Identitätsspalten mit bestimmten Wertebereichen (ranged identity columns), die es ermöglichen, firmenweit die Werte für die Identitätsspalten in den SQL Server CE-Datenbanken automatisch zuzuweisen, ohne Konflikte befürchten zu müssen, wenn diese Zeilen zur SQL Server-Datenbank hochgeladen werden. Dynamische horizontale Partitionen sind ein weiteres Beispiel für die nützliche zusätzliche Funktionalität, die Ihnen bei der zusammenführenden Replikation zur Verfügung steht.
Solche deklarativen Fähigkeiten lassen sich in einer RDA-Anwendung nur schwer von Hand kodieren. Je intensiver Sie in die Anwendungsentwicklung für größere Unternehmen einsteigen, desto eher brauchen Sie die zusammenführende Replikation. Obwohl eine durchdachte Replikation einen gewissen Aufwand für die Vorbereitung, Planung und Konzeption erfordert, zahlt sich der Aufwand durch den wesentlich geringeren Codeaufwand wieder aus, zumindest bei der Entwicklung von komplexeren Anwendungen.
Der Umgang mit Fehlern
Die Programmierobjekte für den SQL Server CE liefern wie die für den SQL Server Fehlerinformationen in Form einer Fehlersammlung. Im Fall der ADOCE-Objekte, die für die Verbindung zum SQL Server CE eingesetzt werden, liegt diese Fehlersammlung im Connection-Objekt. Was die SQL Server CE-Objekte anbetrifft, mit denen die Verbindung zum SQL Server über die ISAPI-DLL hergestellt wird, gibt es im RemoteDataAccess-Objekt und im Replication-Objekt Fehlersammlungen, die aber ErrorRecords genannt werden und nicht Errors.
Wie bei der ADO-Programmierung führt ein Fehler bei einem Methodenaufruf dazu, dass ein oder mehrere Fehlerobjekte in die Sammlung aufgenommen werden und ein Standardfehler gemeldet wird, zum Beispiel ein Visual Basic-Fehler. Zur Bearbeitung der Fehler geht man die Sammlung durch und zeigt dem Anwender die entsprechenden Informationen an.
Zwei Dinge unterscheiden die Fehlerbearbeitung für den SQL Server CE von der Fehlerbearbeitung im SQL Server. Erstens weichen die Fähigkeiten von eMbedded Visual Basic im Umgang mit Fehlern von denen ab, die Visual Basic aufzuweisen hat. Am ehesten ließe sich die Fehlerbearbeitung unter eMbedded Visual Basic noch mit dem vergleichen, was mit VBScript in ASP-Seiten zur Verfügung steht. Zweitens bietet der SQL Server CE keine Fehlerbeschreibungen (error strings) an, damit der Speicherbedarf möglichst klein bleibt. Statt dessen liefert er nur Fehlernummern. Die dazugehörige Beschreibung wird sich der Entwickler aus den Books Online heraussuchen müssen.
Wenn Ihre Anwendung also einen SQL Server CE-Pull von Daten in die SQL Server CE-Datenbank versucht, während sie noch über eine offene ADOCE-Verbindung zu dieser Datenbank verfügt, wird ihr ein "Unspecified Error" gemeldet und kein aussagekräftigerer Fehler wie "kann nicht mehrere Verbindungen zur selben Datenbank herstellen".
Eine weitere Schwierigkeit ergibt sich bei der Programmierung der Fehlerbearbeitung für den SQL Server CE aus der beschränkten Entwicklungsumgebung. So hat eMbedded Visual Basic zum Beispiel nicht die Fähigkeiten wie Visual Basic, was das Abfangen von Fehlern angeht. Sie können nach dem Auftreten eines Fehlers nicht zu bestimmten Zeilen gehen.
Ihre einzigen On Error-Optionen sind GoTo 0 und Resume Next. Auch dadurch ist eMbedded Visual Basic eher mit VBScript vergleichbar. Wann immer ein Fehler auftreten könnte, um den sich Ihre Anwendung kümmern sollte, muss sie sich an die folgenden Schritte halten:
Schalte die Fehlererkennung ab.
Rufe die SQL Server CE-Methode auf.
Überprüfe, ob ein Fehler aufgetreten ist.
Sollte ein Fehler aufgetreten sein, untersuche die Fehlersammlung.
Schalte die Fehlererkennung wieder ein.
In Listing L7 sehen Sie ein Beispiel dafür.
L7 Die Fehlererkennung und Bearbeitung ist nicht ganz einfach
Attribute VB_Name = "SQLCEErrorHandle"
On Error Resume Next
Set refRS = refConn.Execute("SELECT * FROM MyXTable")
If Err.Number = 0 Then
Do Until refRS.EOF
Print refRS.Fields(0) & " : " & refRS.Fields(1)
refRS.MoveNext
Loop
Else
Dim refError As ADOCE.Error
For Each refError In refConn.Errors
MsgBox refError.Number & " : " & _
refError.Source & " : " & _
refError.Description
Next refError
End If
On Error GoTo 0
Vor dem Methodenaufruf muss die Anwendung die normale Fehlererkennung abschalten, weil die normale Fehlererkennung das Programm anhält. Der Umgang mit Fehlern ist in eMbedded Visual Basic vermutlich nicht so komfortabel, wie Sie es erwarten, aber für die anstehenden Aufgaben reicht es aus.
Fazit
Wer sich mit der Entwicklung von SQL-Anwendungen für den Windows-Desktop auskennt, wird in der SQL Server 2000 Windows CE Edition vieles vorfinden, was ihm vertraut ist. Es gibt eine ganze Reihe alter Bekannter, wie zum Beispiel die SQL-Datenbankbefehle und die Programmierschnittstellen von ADOCE und OLEDB CE. Neu ist dagegen das Verbindungsmodell, das der SQL Server CE für die Überführung der mobilen Daten in den zentralen Datenspeicher benutzt. Hier wird sich wieder der Programmierer schnell zurecht finden, der bereits Webanwendungen entwickelt hat.
Dieses Produkt stellt im Prinzip eine leistungsfähige, Client-orientierte Datenbankmaschine dar, mit der Sie die Datenbewegungen zwischen den mobilen und nicht immer mit der Zentrale verbundenen Geräten und dem zentralen Datenspeicher koordinieren können.
Natürlich schlägt sich SQL Server CE auch als eigenständige Datenbank recht ordentlich.