WindowsCE/PocketPC und Datenbanken
Auf vielfachen Wunsch werde ich die ADO für CE anhand einiger Beispiele beschreiben (so gut ich kann). Wer sich vorstellt, CE kann dieselbe umfangreiche Unterstützung zur Behandlung von Daten zur Verfügung stellen, wie es aus Umgebungen wie z.B. Desktop -VB selbstverständlich ist, der irrt. Das liegt sicherlich an den nur begrenzt zur Verfügung stehenden Ressourcen, aber auch an der relativ frühen Umsetzung der Datenzugriffskomponenten. Geschwindigkeit beim Zugriff und komfortables Handling auch in Bezug auf Steuerelemente sind nur mit einigem Einsatz zu erreichen.
Die Versionen
Meine ersten Erfahrungen habe ich mit ADOCE 2.0 gesammelt, auf frühere Versionen werde ich deshalb nicht eingehen. Die im Moment aktuelle Version ist 3.1. ADOCE ist ein Derivat der ADO, Microsofts hauseigenem Datenzugriffskomponenten. Es wird aber nur ein sehr rudimentärer Funktionsumfang geboten, der einfache Auswahl- und Aktionsabfragen ermöglicht. Der wohl gravierendste Unterschied (neben allgemeinen Funktionserweiterungen) zwischen der Version 2.X und den 3.X-Versionen liegt in der Möglichkeit, andere als die interne Datenbank (Objektstore) zu benutzen.
Der ObjectStore stellt einen vom System reservierten Speicherbereich dar, der Daten in „nicht -Dateiform“ darstellt. Nachteil dieses Konzepts ist die Einmaligkeit der Objektnamen innerhalb dieses Bereiches, d.h. wenn zufällig zwei Applikationen existierten, die per ADOCE Tabellen mit dem selben Namen bearbeiteten, so kam es unweigerlich zum Crash.
Die Version 3.0 ermöglichte erstmals den Zugriff auf cdb -Daten (Dateien der Pocket -Version von Access) über einen Datenquellennamen (DSN).
Aktivierung der Datenzugriffskomponenten
Die aktuelle eVB -Version wird mit den ADOCE -Komponenten der Version 3.0 ausgeliefert. Ein aktuelles Projekt wird zum „datenbankfähigen“ Projekt, wenn ein Verweis auf die Datenzugriffskomponente erzeugt wird:
Durch diesen Eintrag (zu erreichen unter „Projekt/References) wird eine Objektreferenz zu ADOCE erstellt, die die Erzeugung und Benutzung von ADOCE -Objekten im aktuellen Projekt ermöglicht.
Die Sammlung der ADOCE -Objekte besitzt 5 Objekte:
Connection
Error
Field
Fields
Recordset
Alle anderen vom “normalen” ADO bekannten Objekte wie beispielsweise Command, Record und Stream sind unbekannt. Der erste Schritt für Desktop - ADO -Benutzer, sich mit ADOCE anzufreunden ist dies zu akzeptieren.
Loslegen...
Um auf Daten zugreifen zu können braucht man Daten in einer Tabelle. Logisch. Leider haben wir im Moment noch keine Tabelle und auch keine Daten. Fangen wir also mit der Definition einer Tabelle an. Der Einfachheit halber werde ich zu Beginn den ObjectStore als Datenbank benutzen, die Erstellung von Bedingungen kommt später.
Als erstes definiere ich ein Objekt vom Typ Recordset. Ein Connection -Objekt ist für diese Art des Datenzugriffs nicht erforderlich, da der Weg zur Datenbank (in diesem Fall ja der ObjectStore) eindeutig gekennzeichnet und dem System bekannt ist:
|
dim rs As ADOCE.Recordset |
Die explizite Definition des Recordset -Objektes als “ADOCE.RECORDSET” ist zwar nicht nötig (alle Variablen in vbscript sind ja Variants), hilft aber ungemein, da die IDE ab nun das „Autovervollständigen“ für die Objektmethoden und Eigenschaften anzeigt.
|
Set rs = CreateObject("ADOCE.RecordSet.3.1") |
Als Besonderheit sei hier vermerkt, daß die Definition des Objektes ADO -Versionsabhängig ist. Unter ADO2.X wurde das Recordset nur als "ADODB.RECORDSET" definiert, ab der Version 3.0 ist die Angabe der Versionsnummer erforderlich.
Das Objekt rs ist hiermit erstellt, hat aber noch den Zustand “geschlossen”. Da als erstes eine Tabelle erzeugt werden soll, muß die SQL -Syntax für das Erstellen einer Tabelle bekannt sein:
CREATE TABLE Tabellenname (Feldname1 Feldtyp1 [,Feldname2 Feldtyp2])
Der Tabellenname stellt den Datenbank-Objektnamen für die Tabelle dar, dahinter werden in Klammern die Feldnamen mit den jeweils durch Komma getrennten Datentypen angeordnet.
ADOCE kennt folgende Datentypen
| Datentyp | Beschreibung |
| Varchar[(n)] | Nullterminierter Unicode- (2 Byte pro Zeichen) String der Länge n, maximal 255 Zeichen. Ohne Angabe wird 1 angenommen. |
| Text | Variable Länge mit bis zu 32000 Zeichen |
| Varbinary[(n)] | Binärwert mit bis zu 256 Bytes Breite Ohne Angabe wird 1 angenommen. |
| Long Varbinary | Binärwert mit weniger als 65,469 Bytes Breite. (OLE-Objekt) |
| Integer, int | 4-Byte Ganzzahl mit Vorzeichen |
| Smallint | 2-Byte Ganzzahl mit Vorzeichen |
| Float | Fließkommawert doppelter Genauigkeit |
| Datetime | Datum/Uhrzeit |
| Bit | Boolescher Wert.0 entspricht FALSCH, ungleich 0 entspricht WAHR |
| Uint | 4-Byte Ganzzahl ohne Vorzeichen |
| Usmallint | 2-Byte Ganzzahl ohne Vorzeichen |
Als Praktisches Beispiel soll eine Tabelle erzeugt werden, die Namen, Vornamen und Personalnummern enthält:
create table tblPersonal(idPersonal int,strName varchar(50),strVorname varchar(50))
um nun die Tabelle zu öffnen muß der eben erzeugte SQL-String von ADOCE ausgeführt werden:
|
rs.open "create table tblPersonal(idPersonal int,strName varchar(50),strVorname varchar(50))" , "", 0, 1 |
Dieser Konstrukt dürfte ADO -erfahrenen Entwicklern doch etwas seltsam vorkommen, da hier ein Recordset -Objekt zum Ausführen von Aktionsabfragen benutzt wird. Das Ganze ist aber einfach zu erklären: hier gibt’s keine Execute -Methode des Connection -Objektes!
Nachdem die Tabelle erzeugt ist, soll sie mit Hilfe von Anfügeabfragen gefüllt werden. Auch dazu muß erst der SQL -String entworfen und mittels des Recordset -Objektes ausgeführt werden. Das Recordset Objekte hat im übrigen noch immer den Zustand „geschlossen“, da die obige Aktionsabfrage kein Recordset -Objekt zurückgeliefert hat.
INSERT INTO Tabellenname [(Spaltenname1,Spaltenname2, …)] VALUES (Wert_für_Spalte1,Wert_für_Spalte2, …)
Der durch „Tabellenname“ spezifizierten Tabelle wird also ein Datensatz hinzugefügt, dessen Zelleninhalte mit den durch „values“ spezifizierten Werten gefüllt werden.
Das sieht für das Personaltabellenbeispiel dann so aus:
|
rs.open
"insert into tblPersonal(idPersonal,strName,strVorname) values(1,'Hennemann','Heinz')" |
Da auch diese Aktionsabfrage kein Recordset zurückliefert hat das rs -Objekt noch immer den Zustand “geschlossen”.
Und nun zum größten WindowsCE/PocketPC –Manko in Bezug auf Datenbanken und eVB: Datengebundene Steuerelemente sind unbekannt. Das stellt aber nur auf den ersten Blick ein Problem dar, es animiert einfach zu etwas „Mehraufwand“ bei der Programmierung.
Um ein (in diesem Fall "cmbPersonal" genanntes) Kombinationsfeld mit Daten zu füllen, müssen die Daten also quasi „zu Fuß“ aus der Tabelle geholt und in das Steuerelement eingesetzt werden werden:
|
Dim n as long |
..Und schon sind die eben erzeugten Daten im Kombinationsfeld. Bei Auswahl eines Wertes erhält man mittels
|
' |
die Personalnummer der ausgewählten Person.
Da es sich hier nur um ein Beispielprojekt handelt, muß die Tabelle zum Programmende wieder aus dem Objektstore beseitigt werden (wird sie nicht gelöscht, so wird beim nächsten Programmstart ein Laufzeitfehler erzeugt, da die Tabelle ja bereits existiert!) Dies geschieht mittels einer weiteren Aktionsabfrage:
|
rs.open "drop table tblPersonal" |
Zugegeben, nicht besonders sinnvoll als Applikation, aber zum Verständnis der ADO -Objekte und Abfragetypen sicherlich ausreichend.