Office: (Office 2010) Verweisproblem in .mde

Das seh ich mir dann genauer an, ich hab den Screenshot vom Kunden genommen, um mir das Gefummel im .mde-Direktfenster zu ersparen. Würde mich interessen, ob der Verweis überall fehlt. Aber ich hab alt und neu verglichen ... Der auffälligste Unterschied ist, dass in .mdb und .mde der DAO-Verweis auf dao360.dll führt, in .accdb und .accde auf acedao.dll.

Jein, denn in der .mdb unter 2010 funktioniert das Anpassen, jedenfalls zur Laufzeit. Am Verweis in der Datei selbst wird nichts geändert. Ich nehme an, auch Access 2010 speichert z.B. dao360.dll in einer .mdb / .mde, damit eine ältere Accessversion keine Schwierigkeiten mit dieser .mdb / .mde kriegt, aber anscheinend substituiert Access den Zugriff zur Laufzeit. Ich könnte mir vorstellen, dass hier temporär in der .mde Systemtabellen befüllt werden, die dann wieder gelöscht werden. Und bei diesem Vorgang ist Access 2010 mit einer .mde nicht erfolgreich, mit einer .mdb aber schon.

An ein Rechteproblem hab ich auch schon gedacht, allerdings kann der Zugriff auf die registry m.E. nicht der Hinkefuß sein, siehe oben. Unter Office 2010 sind die Gängelungsmechanismen à la M$ noch vielfältiger geworden als schon in den Vorgängerversionen, vielleicht funkt mir irgendein Protected Document Mode oder sowas dazwischen. Da ist wohl noch einiges an Lernarbeit fällig. Man gönnt sich ja sonst nichts ... ;-)

Danke soweit.

mupan

 

Vielleicht noch mal zur Klärung:
Access passt nicht den Verweis in der MDB selbst an, wenn es auf ein System mit anderer Version kommt!
In der MDB selbst ist nur die GUID der Access-Bibliothek gespeichert - bzw. zwar tatsächlich auch der Name und Major/Minor, aber es interessiert sich ausschließlich für die GUID -, und die ist immer gleich und verweist, je nachdem, was in der Registry unter typelibs\{Access-GUID} steht, auf evtl. unterschiedliche msacc.olbs. D.h., wenn in den Verweisen "Access 11 O. Library" steht und auf einem andern Rechner die DB "Access 14 O. Library" anzeigt, sich gar nichts in der MDB geändert hat, sondern dort nur in der Registry unter der GUID was anderes steht.

Access versucht aber, die Registry beim Start - noch ohne geladene MDB! - zu ändern und auf "sich", also "seine" .olb zu stellen. Ggfls. springt dabei der Installer an. Mit mangelnden Rechten unter Vista/Win7 klappt das nicht.
Auf einem System mit nur einer Access-Version ist das egal und sowieso nicht nötig, aber bei mehreren parallel installierten Versionen gibt's dann Schwierigkeiten.

Summa summarum: Es ist egal, welche Access-Version in den Verweisen eingetragen ist. Auch bei MDE funktioniert eine andere Versionsnummer, da die GUID gleich ist.
Nicht egal ist hingegen, wenn man unter höherer Version entwickelt und möglicherweise Features einbaut, die es nur unter dieser Version gibt. Das kann dann zu Problemen auf einem Zielsystem mit niedrigerer Version führen. Allerdings dann erst zur Laufzeit, und nicht beim Start, wenn etwa ein Formular mit unbekannten Properties geöffnet wird. (Bekannte Meldung: "Sie haben eine Ereignisprozedur Beim_Laden angegeben, die ...blabla...")

Ciao, Sascha

Ciao, Sascha

 

Hi Sascha, hallo ihr anderen,

ich hab ein bisschen weiter geschaut und mittlerweile auch ein paar Tage unter Access 2010 mit unserem Produkt gearbeitet. Weil ich den Eindruck hatte und habe, dass uns hier Informationen von M$ fehlen, um eine echte Lösung zu finden, hab ich das Problem mit dem damaligen Stand crossgepostet im M$-Technet-Forum http://social.technet.microsoft.com/...1-c526fb3e4464 -- ich hoffe, Ihr verzeiht mir den Crosspost, hab Process-Explorer-Log-Extrakte geliefert usw.

Herausgekommen dabei ist bloß, dass mir der Online-Support nicht weiter helfen konnte / wollte. Dabei deutet alles zusammen, vor allem aber das Folgende m.E. deutlich darauf hin, dass mein Problem von M$ verursacht ist, und nicht von einer falschen Referenz oder falschem VBA-Code:

Code:

Bringt euch das auf Ideen? Habt ihr eine Idee, wie ich trotzdem noch zu einer einheitlichen .mde als Auslieferungsformat komme? Eine .accde über eine .accdb zu schreiben ist nicht so sehr mein Problem, auch wenn es lästig ist. Das Unangenehme ist, dass meine Kunden nun gezwungen sind, beim Zukauf einer neuen Maschine entweder alle Maschinen im Betrieb auf 2010 zu aktualisieren, oder von unserem Produkt auf verschiedenen Maschinen verschiedene Versionen zu verwenden, was entweder auf Handarbeit oder ein differenzierteres Verteilkonzept durch den dortigen Admin hinausläuft.