(DIE FOLGENDEN INFORMATIONEN SIND VON MICROSOFT NICHT GEDULDET)
Das ist nur ein einfaches Info-Posting, aber ich dachte, ich sollte eine Frage
behandeln, die dauernd gestellt wird. Sollten Sie sich bei Ihrer Arbeit auf Systemtabellen
verlassen? Diese Frage ist besonders wichtig bei der Replikation, weil ohne den TSI Synchronizer die
Systemtabellen die einzige Möglichkeit darstellen, bestimmte Informationen zu bekommen,
und ich schreibe gerade eine Artikelserie für den Access/Office/VB Advisor über die
Verwendung der Replikations-Systemtabellen, aber es kann auch für andere Dinge wichtig
sein (Ken Getz und Mike Gilbert haben z.B. eine hervorragende dreiteilige Artikelserie
für Informants Microsoft Office
Developer über den Zugriff auf MSysQueries geschrieben).
In einem wichtigen Gespräch mit Kevin Collins, einem Program Manager für Microsoft
Jet, erklärte er unmissverständlich, dass das Jet-Team die TCO (Total Cost of Ownership)
Initiativen von Microsoft sehr ernst nimmt, und ging sogar soweit, zu sagen, dass sie das
Dateiformat überhaupt nicht verändert hätten, wenn es nicht für den Umstieg auf
Unicode notwendig gewesen wäre (das für eine andere Initiative Microsofts wichtig war,
nämlich jene der internationalen Unterstützung, besonders mit all den neuen
"Unicode-only" Sprachen).
Um diese TCO-Richtlinien zu erfüllen müssen alle vorherigen Versionen der Jet-Engine
alle zukünftigen Versionen lesen können. Einfach gesagt heißt dies, dass Jet nicht das
Dateiformat ändern darf oder solche Änderungen erfahren darf, die irgendeine
Microsoft-Anwendung, die ein Feature in einer älteren Jet-Version nutzt, beinträchtigen
könnte, wenn eine neuere Jet-Version verwendet wird. Das bedeutet, solange sich *jemand*
bei Microsoft auf ein Feature in einer Systemtabelle verlässt, können sie die
Systemtabelle nicht ändern!
Das bedeutet auch, während es klar ist, dass sie in Zukunft ADO und Jet OLE
DB-Provider für den Zugriff auf Jet-Datenbanken zu verwenden gedenken und während es
unwahrscheinlich ist, dass es künftig noch mehr als kleine "Bugfix"-Versionen
von DAO geben wird, ist es in Stein gemeißelt, dass DAO 3.6 mit jeder Datenbank arbeiten
wird, die mit irgendeiner zukünftigen Jet-Version erstellt wurde, sei es eine Haupt- oder
Nebenversion. Sie werden keine neuen Features bekommen, aber Sie brauchen sich keine
Sorgen über die Konvertierung bestehenden Codes zu machen, der mit Jet-Datenbanken unter
Verwendung von DAO 3.6/Jet 4.0 läuft. Solange es eine Jet-Engine gibt, wird DAO 3.6 damit
funktionieren.
Was heißt das? Naja, in der Praxis stellen die Informationen und Wraper-Funktionen,
die Ken und Mike für Informant geschrieben haben, eine sichere Methode dar, Abfragen zu
analysieren, die auch in künftigen Versionen funktionieren wird, weil, falls Sie jemandem
eine Jet 8.0 (hypothetische Versionsnummer zwecks Argumentation) Datenbank zur Verwendung
geben, und alles, was Sie haben, ist Jet 4.0, dann muss diese Jet 4.0 Datenbank in der
Lage sein, die Jet 8.0 Datenbank zu lesen. Und wenn sie das Format von MSysQueries
geändert hätten, würde das nicht funktionieren.
Ebenso bei der Replikation. Der Konflikt-Manager und der Code in der msrepl40.dll
hängen ab vom Schema der Replikations-Systemtabellen. Also können Sie nicht in einer
Weise geändert werden, die evtl. eine ältere Jet-Version zum Abstürzen bringt, wenn man
versucht, Datenbanken zu lesen, die mit Jet 6.0 oder so erzeugt wurden.
Werden wir eine Jet 6.0 oder Jet 8.0 zu sehen bekommen? Wer weiß? Ich bin kein
Hellseher. Ich zweifle sogar, ob Microsoft eine Antwort für *diese* Frage hat. Die
Kernaussage dieses Postings ist, dass alle früheren Hinweise wie "keine Garantie,
dass dies in zukünftigen Versionen funktionieren wird" in Hinblick auf die
Jet-Systemtabellen jetzt null und nichtig sind.
Aber überlegen Sie sich: Würde eine Änderung die alte Version beeinträchtigen? Ich
gebe ein paar einfache Beispiele, die Ihnen dabei helfen sollen, festzustellen, ob Ihre
Abhängigkeit von den Systemtabellen eine ist, die beeinträchtigt werden kann oder nicht.
- Nehmen wir an, Sie haben eine Anwendung, die davon abhängt, wieviele Spalten es in der
Tabelle MSysQueries gibt. Können Sie sich darauf verlassen? Die Antwort lautet NEIN,
weil Jet eine Spalte hinzufügen könnte, ohne die bestehende Jet 4.0 in Mitleidenschaft
zu ziehen.
- Was ist, wenn Ihre Anwendung von einem Datentyp oder Wert in einer bestimmten Spalte
abhängt? Können Sie sich darauf verlassen? Die Antwort lautet JA, weil eine in
dieser Hinsicht veränderte Jet > 4.0 die Jet 4.0 abstürzen liesse, beim Versuch eine
solche Datenbank zu öffnen.
- *Was ist, wenn Ihre Anwendung von Features abhängt, die NYI (not yet implemented) sind,
z.B. der Nullwert der "InvolvedObjects" Spalte in MSysConflicts? Können Sie
sich darauf verlassen? Die Antwort ist NEIN, weil niemand in Jet oder sonstwo
derzeit von diesem Wert abhängig ist. Hoffentlich werden sie dem in zukünftigen
Versionen eine Funktionalität geben.
Wenn Sie also ein solches Feature in einer Jet-Systemtabelle verwenden, unterziehen Sie
es diesem einfachen Test und stellen Sie fest, ob es auch sicher in zukünftigen Versionen
verwendet werden kann. Am besten lässt sich die Sache zusammenfassen, indem man sagt,
dass die Verwendung der Systemtabellen weiterhin undokumentiert ist, aber aus
unabhängigen Gründen (TCO) auch in künftigen Jet-Versionen fuktionieren wird.
