Die gute Nachricht zuerst:
Obwohl ich mich noch nie mit dem Thema beschäftigt hatte, nein noch nicht einmal mit den entsprechenden Projekttypen im Studio herumgespielt, habe ich in nur 2 Tagen eine funktionierende Datenbankanwendung für den Pocket PC erstellt.
Das lag nicht zuletzt daran, dass die eingeschänkten Funktionen, die einem das .NET (Compact) Framework und Visual Studio hier bieten, ziemlich ausgereift scheinen und einfach problemlos funktionieren. Vieles geht zwar nicht, aber das was geht, funktioniert einfach.
Auch sehr angenehm, wenn auch schweinelangsam, ist der ins Studio integrierte Pocket PC Emulator, mit dem man quasi einen kompletten Pocket PC inkl. Windows-Betriebssystem und dem ganzen Schnickschnack auf seinen richtigen Rechner bekommt, und so auch ohne Anschluss eines echten PDA entwickeln kann.
Aber auch das geht: einfach PDA anstecken, Verbindung via ActiveSync herstellen und schon findet auch Visual Studio das Gerät - und schickt, wenn man möchte, die Anwendung beim Debuggen nicht mehr an den Emulator sondern direkt auf den PDA. Was auch zu empfehlen ist, denn im Vergleich schnitt mein Test-PDA (älteres Yakumo-Modell, 233 MHz) erheblich schneller ab, als der Emulator.
Hier noch 2 Screenshots, die symbolisch zeigen wie die Entwicklung so abläuft - und vielleicht dem ein oder anderen Lust machen, es mal selbst auszuprobieren? ;-) (Anklicken zum Vergrößern)
Und nun zum schlechten Teil:
Die "Datenbank" SQL Server 2005 Mobile könnte man wohl eher als sehr extrem eingeschränktes MS Access bezeichnen. Das Teil kann wirklich nichts außer Daten bereithalten. Zu Gute halten muss man dem System, dass es das einzige gewesen ist was ich finden konnte, was sowohl mit .NET 2.0 problemlos funktioniert, als sich auch verschlüsseln lässt. Denn wer will schon seine Datenbestände offen mitliefern, wenn der Kunde dafür mehrere hundert Euro zahlt? Genau das war das Problem bei allen vorher evaluierten Systemen, insbesondere dem Pocket Access Format (da geht das Passwort beim Konvertieren über ActiveSync einfach flöten).
Nach mehreren Stunden klappte dann auch der Datenimport. Hierfür habe ich meinen Datenbestand aus Access heraus via Upsizing-Assistent zu ner SQL Server 2005 Datenbank gemacht (funktioniert problemlos) und anschließend nach dieser Anleitung publiziert. Dieser Vorgang ist für scheduled Tasks sicherlich nicht schlecht, aber für einen einmaligen Import hätte ich mir das wie früher im alten 2000er DTS gewünscht - zumal das mit den verschiedenen Benutzern usw. bei mir nicht funktionieren wollte, und ich am Ende entnervt mit sa und Administrator gearbeitet habe.
So, nun waren die Daten in der Datenbank, und die Datenbank im Projekt eingebunden - das Typed Dataset erstellt (was später ausgetauscht wurde, weil viel zu langsam) und nun konnte es losgehen.
Der nächste Knackpunkt war dieser hier. Nachdem ich dann also rausgefunden hatte, dass die Syntax genauso beschränkt ist wie beim Access-Provider, lief es dann aber ...
... bis die Anwendung stand in der Entwicklung problemlos weiter. Dann ging es ans Testen: und siehe da - alles funktionierte, aber seeeeehr langsam. Für das Abfragen von ca. 6 Ergebnis-Datensätzen aus 1500 insgesamt benötigte es ~ 10 Sekunden auf o.g. PDA. Natürlich absolut inakzeptabel. In der Folge habe ich dann das Ganze von TypedDataSets auf ein eigenes Objekt und dazugehörige generische Liste gefüllt per DataReader umgestellt, was das Ganze dann nochmal um 50% schneller machte. Aber auch 5 Sekunden sind für diese Abfrage zu lang - mussten nun aber aus aktuter Über-der-Tastatur-einschlaf-Gefahr für die Präsentation reichen ;-)
Fazit
Ich weiß nicht so recht, ob ich nun hoffen soll dass der Prototyp gut ankommt und die Entwicklung weitergeht, oder ob ich nicht doch froh bin, wenn dieser Kelch an mir vorüber geht. Denn so einfach die Entwicklung mit Visual Studio ist und so viel Spaß sie macht, so ein Krampf ist die mobile SQL Server Version. Denn wenn man sich einmal mit den beschränkten Funktionen arrangiert, kommt der Performance-Hammer. Falls das Produkt also wirklich entwickelt wird, werde ich mich als erstes nach einer ordentlichen Alternative dazu umsehen.
Abschließend noch vielen Dank an Andreas Roth und Roman Pittroff für ihre wegweisenden Tipps ;-)
