(DE VOLGENDE INFORMATIE IS NIET GOEDGEKEURD DOOR MICROSOFT)
Dit is maar een eenvoudige info-post, maar ik vond dat ik een vraag moest behandelen die constant wordt gesteld. Kun je vertrouwen op systeemtabellen als je je werk doet? Deze vraag is vooral van belang bij replicatie, omdat buiten de
TSI Synchronizer
de systeemtabellen de enige manier zijn om wat informatie te krijgen. Ik ben op het ogenblik een serie artikelen aan het schrijven voor Access/Office/VB Advisor over het gebruik van de replicatie-systeemtabellen, maar het kan ook van belang zijn voor andere behoeften (Ken Getz en Mike Gilbert hebben bijvoorbeeld een excellente driedelige serie artikelen geschreven voor Microsoft Office Developer van
Informant over het parsen van MSysQueries).
In een belanrijk gesprek met Kevin Collins, een programma-manager voor Microsoft Jet, zei hij op ondubbelzinnige wijze dat het Jet-team de TCO(Total Cost of Ownership)-initiatieven van Microsoft heel serieus neemt; hij ging zelfs zover om te beweren dat ze het bestandsformaat *helemaal niet* zouden hebben gewijzigd als dat niet vereist was vanwege de overgang naar Unicode (wat belangrijk was voor een van de andere initiatieven van Microsoft, namelijk die van internationale ondersteuning, vooral met alle nieuwe "Alleen Unicode"-talen).
Om tegemoet te komen aan de TCO-richtlijnen, moeten daarom alle eerdere versies van de Jet engine alle toekomstige versies kunnen lezen. Eenvoudig gezegd betekent dat, dat Jet het bestandsformaat niet mag wijzigen, of andere veranderingen mag aanbrengen die er voor zouden kunnen zorgen dat een Microsoft-applicatie die gebruik maakt van een feature in een oudere versie van Jet stukloopt als er een nieuwere versie van Jet wordt gebruikt. Dit betekent dat, zo lang *iemand* binnen Microsoft steunt op een feature in een systeemtabel, ze de systeemtabel niet kunnen veranderen!
Dit betekent ook dat, terwijl duidelijk is dat ze in de toekomst ADO en de Jet OLE DB willen gebruiken voor toegang tot Jet-databases, en terwijl het onwaarschijnlijk is dat er ooit een type point release van DAO zal komen die meer doet dan het oplossen van bugs, het nu zwart op wit staat dat DAO 3.6 zal werken met elke database die met een toekomstige versie van Jet werkt, groot of klein. Je zult nergens nieuwe features erbij krijgen, maar je hoeft je niet druk te maken over het converteren van bestaande code die met Jet-databases werkt, die gebruik maken van DAO 3.6/Jet 4.0. Zolang er een Jet engine is, zal DAO 3.6 ermee draaien.
Wat betekent dit? In praktische bewoordingen zijn de informatie- en wrapper-classes die Ken en Mike hebben geschreven voor Informant nu voor eeuwig vastgelegd als een manier om queries te parsen, die niet stuk zal lopen in toekomstige versies, want als je iemand een Jet 8.0-database zou geven (een hypothetisch versienummer om de zaak duidelijk te maken) en je hebt alleen maar Jet 4.0, dan moet de Jet 4.0-database de Jet 8.0-database kunnen lezen. En als ze het formaat van MsysQueries zouden wijzigen, zou het niet werken.
Voor replicatie geldt iets soortgelijks: de Conflict Viewer en de code in msrepl40.dll hangt af van het schema in de replicatie-systeemtabellen. Ze kunnen dus niet worden veranderd op een manier die een eerdere versie van Jet zou kunnen laten stuklopen als bijvoorbeeld een database die met Jet 6.0 is gemaakt gelezen moet worden.
Waar kunnen we Jet 6.0 of Jet 8.0 verwachten? Wie weet? Ik ben geen helderziende, ik vraag me af of zelfs Microsoft *deze* vraag kan beantwoorden. Het punt waar deze post om draait is dat al het vroegere advies van "we garanderen niet dat dit in toekomstige versies nog werkt" met betrekking tot de Jet-systeemtabellen nu niet meer geldt.
Maar wees voorzichtig en let hierop: zorgt de wijziging dat de oude versie stukloopt? Ik zal wat simpele gevallen doornemen om je te helpen bepalen of je afhankelijkheid er eentje is die stk kan lopen of niet.
-
Laten we zeggen dat je een applicatie hebt die ervan afhangt hoeveel kolommen er zijn in de MsysQueries-tabel. Kun je hierop vertrouwen. Het antwoord is NEE, want Jet kan een kolom toevoegen en dat laat het bestaande Jet 4.0 niet stuklopen.
-
Wat als je applicatie afhangt van het datatype en de waarde van een bepaalde kolom? Kun je hierop vertrouwen? Het antwoord is JA, want als Jet 4.0 zoiets zou veranderen, loopt Jet stuk als het deze database probeert te openen.
-
*Wat als je applicatie afhangt van features die NYI (nog niet geimplementeerd) zijn, zoals de Null-waarde van de "InvolvedObjects"-kolom in MsysConflicts? Kun je hierop vertrouwen? Het antwoord is NEE, want niets in Jet of elders hangt nu van deze waarde af. Hopelijk zorgen ze dat dit werkt in toekomstige versies.
Als je dus een dergelijke feature gebruikt in een Jet-systeemtabel, loop even langs deze test en bepaal of het al dan niet veilig is om te gebruiken in toekomstige versies. We kunnen het beste stellen dat het gebruik van Jet-systeemtabellen nog steeds niet wordt ondersteund, maar dat het om niet-gerelateerde (TCO) redenen blijft werken in toekomstige versies van Jet.
