Office: (Office 2010) Verweisproblem in .mde

Im Anhang sind Fehlermeldungen enthalten, die nur in einer .mde und nur unter Access 2010 reproduzierbar beim Start aufkommen. Die zu Grunde liegende .mdb, eine aus der .mdb erzeugte .accdb und eine aus der .accdb erzeugte .mde erzeugen keine Fehler. Ich vermute deshalb stark, dass es sich um ein Verweisproblem handelt. Die letzte im Anhang enthaltene Abbildung listet die "Verweise". Welche der dort aufgeführten Bibliotheken wird hier nicht gefunden, was sagen euch die Fehlermeldungen? Oder ist es kein Verweisproblem?

Danke fürs Mit-Denken.

mupan

:)

 

Hallo mupan!

Versuch doch einfach die vwerweise in eine txt. zu speichern

Code:

und beim öffnen der db(mde) zuladen mit folgender Prozedur (aus db-wicki)
Code:

 

Hhhmmm ... die erste und letzte Fehlermeldung auf der ersten Seite des PDF's macht mich ein wenig stutzig ... Undefined Function 'Mid'/'IsNull' in Expression.

Das er Standard-Funktionen von VBA anmeckert kenn ich nur wenn ich mal wieder durch zuviel "Rumspielerei" einiges massiv in Access durcheinander gebracht habe.

Da hilft dann bei mir nur alles in eine neue DB laden, manchmal hilft auch ein Aufruf mit dem Parameter /decompile.

Schonmal probiert alles in eine frische neue DB zu laden und dann daraus die Compilierung zu erstellen, bzw. mit decompile alles zu säubern und dann nochmal die Compilierung zu machen?

Denke also weniger das es mit einem Verweis zu tun hat. Möglicherweise hat es vielleicht was damit zu tun das in Access 2010 VBA7 läuft und nicht mehr VBA6. Aber an sich sollte es eigentlich abwärts kompatibel sein.

Gruß

Rainer

 

Hallo
zwischen den Zwei funktionen von swati
könntest Du auch noch das laufen lassen:
Überflüssige Verweise Löschen:
Code:

ahhh fast Vergessen:
wenn Du den "Call VerweiseTesten" nicht löschen möchtet
musst Du ja noch das haben:

Code:

 

Hi, danke für die Antworten.

@Rudolf: Danke für den Code. Wenn unbedingt nötig, restauriere ich Verweise per VBA. Davor will ich aber mehr wissen, und mich möglichst nur mit problematischen Verweisen (ich vermute: DAO: dao360.dll -> acedao.dll, bin aber nicht sicher) befassen, und dazu muss ich die problematischen ausfindig gemacht haben. Und damit die .mde unter allen Accessversionen hochfährt, das ist nämlich die Anforderung, müsste ich ein If oder Select einbauen, und so etwas fliegt einem erfahrungsgemäß beim Kunden um die Ohren. Verweise anzupassen sollte eigentlich Aufgabe von Access / Windows sein, nicht? Siehe auch meinen anderen thread zum DAO-Verweis. In diesem thread geht es mir darum, genauer rauszukriegen, welches der problematische Verweis ist, wenn es denn ein Verweisproblem ist.

@Rainer: Ja, im äußersten Fall habe ich auch schon ein decompile auf einer .mdb-Kopie gemacht, oder einzelne Objekte / die ganze .mdb neu aufgebaut aus einem Textdump. Dagegen, dass es diesmal eine korrupte .mdb ist, spricht, dass .mdb, .accdb und .accde problemlos hochfahren. -- IsNull, Mid: Ja, das macht mich auch stutzig. Deshalb bin ich von meiner Theorie, dass DAO der Haupt- oder einzige Verursacher sei, auch nicht 100 Pro überzeugt. Der ActiveX Compatibility Manager (ACM) von Nirsoft zeigt mir an, dass das Office-2010-Setup mscomctllib und mscomct2 deaktiviert. Aber auch nach einer Aktivierung in ACM fährt die .mde nicht hoch.

Also entweder habe ich es mit einer hübschen Kombi von Problemen zu tun, oder ich stocher immer noch in der falschen Richtung rum. Ich mag gar nicht an den Aufwand denken, dann für das Workstation-Setup beim Kunden eine hübsch scriptfähige Lösung zu suchen, wenn ich nur erstmal das Problem identifiziert habe ...

 

Hhhmmm ... wenn es ein Verweis sein sollte der hängt, dann würde mir ja eher die Verweise aus dem Verzeichnis OFFICE14 ins Auge springen. Einzig aus der Überlegung heraus das die Kompilierung als ACCDE läuft aber nicht als MDE ... die Überlegung dabei es sollte mal kein grundsätzliches Verweisproblem sein (wenn man von einem Verweisproblem ausgeht) sondern eher ein Datenbank-Version abhängiges Verweisproblem sein.

Kannst Du eine Muster-DB basteln die mit den gesetzten Verweise wie Du sie gepostet hast auch nicht als MDE läuft und die dann testen wie es ohne die Verweise auf MSWORD.OLB und MSO.DLL läuft?

Grundsätzlich zum Thema Verweise: Mal versucht die ganzen Verweise ohne Major- und Minor-Angabe zu setzen wie es dann aussieht (also beides auf 0)?

Ansonsten - falls machbar/verfügbar - prüfen wie sich das Ganze verhält wenn Du die Compilierung unter Access 2007 erstellst. Rein aus der Überlegung heraus festzustellen ob es sich um ein allgemeines Problem handelt (wie z.B. Verweisproblem) oder ein Access 2010 typisches Problem.

Quasi so lange zurück gehen bis es funzt und dann Schritt für Schritt nachvollziehen wann es beginnt zu hängen ... ist allerdings bei dem Problem nicht so wirklich einfach. ^^

Gruß

Rainer

 

Hallo probier doch einfach mal Deine db mit mit folgenden tool

Willkommen bei Team-Moeller.de - TM-RebuildDatabase

von Thomas Möller zu "reparieren"
Möglicherweise ist ja Deine Db "korrupt" geworden. Bei mir hat das schön öfters die "lösung" bei seltsamen Fehlern gebracht. so wie speichern in Formulkaren, Modulen "nicht möglich". Läuft allerdings nur unter Access 07 bis 00

 

Da war ich wohl bei dem Versuch, einem Cross-Post-Vorwurf zu entgehen, zu knapp: Die .mde schreibe ich auf einer Office-9-Maschine. So war bisher sicherzustellen, dass alle Kunden, die alle Office-Versionen seit 9 (2000) im Einsatz haben, unser Produkt ohne Schwierigkeiten einsetzen können. Bisher ... bis zum Office 2010. Die Kompilierung verläuft ohne Schwierigkeiten. Die Anpassung der Verweise zur Laufzeit funktioniert in allen Office-Versionen bisher. Bei Office 2010 funktioniert das auch, prinzipiell, beim Office-Link etwa, der lautet unter Access 2000 natürlich auf ...\OFFICE9\... Nur dass die .mde mit diesen Fehlermeldungen reagiert und dann nicht richtig läuft. Die .mdb macht diese Schwierigkeiten nicht.

Ich verstehe deinen Vorschlag so, dass ich in einer Kopie der .mdb einzelne Verweise rausnehme und so den Schuldigen ermittle. Das kann ich probieren. Aber ob ich dann noch kompilieren kann? Ich fürchte, da wird dann einiges fehlen und umprogrammiert werden müssen.

Werden von Access gesetzt, ich hab die nur ausgelesen.

Wohl wahr ;-) Danke für deine Hinweise bis jetzt. Zum Vorgehen: siehe oben.

mupan

 

Das war die Überlegung dabei. *wink.gif*

Probiere doch mal einfach nur eine kleine Test-DB in der Du die Verweise setzt und für jeden Verweis eine kleine Prozedur bastelst die bei absolut korrektem Ablauf eine MsgBox mit True oder wenn mit False zurück liefert. Das sollte ja in ein paar Minuten geschehen sein.

Gucke mal ob dann mit dieser DB Dein Problem auch autritt bei der Kompilierung in eine mde. Wenn ja ... dann hast Du den optimalen Testkandidaten in dem verweise schnell rauszunehmen sind und nur eine Code-Stelle auskommentiert werden muss.

So kannst Du Verweise direkt über die GUID setzen und dabei auch die Angaben für Major und Minor beeinflussen:

Code:

Meines Wissens nach ist die Angabe 0 jeweils für Major und Minor, dass dann nicht der Verweis auf eine bestimmte Version angepasst wird auf dem Zielrechner sondern auf die aktuellste vorhandene Version auf dem Zielrechner. Das kann manchmal helfen wenn es Versionproblematiken bei den Verweisen gibt.

Gruß

Rainer

 

Hallo Rainer, danke dir. Da knüpfe ich direkt an am Montag, 11.10., dann sitze ich wieder an der Office-2010-Maschine.

 

Die Verweise machen mich mich auch immer bei unterschiedlichen Access-Versionen bei den Enbenutzer der DB`s fertig, daher ist der Hinweis mit dem "0-Setzen bei dem GUi-Eintrag "Gold" wert. Dann wird je nach Access-Version des Rechner wo db/mde aufgerufen wird der ichtige Verweis auktiviert.i
Den Hinweis von Rainer wollte ich noch mit einem kleinen Beispiel unterstützen:

Verweise wieder herstellen:
Code:

Verweise neu setzten:
Code:

 

Ich kann dem DIskussionsverlauf nicht folgen. *wink.gif*
Ich dachte, dass von einer MDE die Rede sei.
Wie soll man in der die Verweise anpassen? Das geht doch nicht und all der Code ist umsonst.

Das ist ja gerade sein Problem: Die Verweise haken fest und können in der MDE NICHT geändert werden, so dass es zu diesen Fehlern kommt.

Offensichtlich fehlt in seinem Screenshot in der Verweisliste am Ende der wichtigste Eintrag: der Access-Verweis. Schätzungsweise kann gerade der nicht auf die A14-Lib geändert werden, so dass A2010 Kompatibilitätsprobleme mit der Typelibrary bekommt.
Und dafür wiederum ist verantwortlich, dass A2010 im Gegensatz zu A2007 den Eintrag in der Registry nicht ändern kann, wenn es keine Admin-Rechte hat.

Test wäre also:
A2010 auf dem Zielrechner "Als Adminstrator" starten und dann die MDE laden. Mal sehen, ob dann die Fehlermeldungen immer noch kommen.

Ciao, Sascha

 

Er soll - zumindest meine Intention - nicht während der Laufzeit die Verweise einstellen, sondern bei der Entwicklung. Und ich meine mal gelesen zu haben, dass das setzen der Verweise über die GUID mit Major/Minor auf 0 eben den Verweis beim Laden auf die aktuellste Version die verfügbar ist setzt.

Oder habe ich da was Falsches gelesen, bzw. mir was falsch gemerkt?

Gruß

Rainer

 

Rainer, auch das kann ich nicht nachvollziehen.
Warum soll er während der Entwicklung Verweise per Code setzen? Das behebt doch das Problem mit der MDE nicht?
Ich glaube kaum dass eine Library auf einer falschen COM-Versionsnummer aufsetzt und dies das Problem verursacht. Denn auf der Entwicklermaschine hat man meist nur eine Version in der Registry stehen.
IMHO kümmert sich VBA eh nicht um die Versionsnummern, sondern nur die Typelib-GUID.

Er hat bisher auch nicht klar erläutert, WO die Fehler auftreten: Auf eigenen Rechnern oder nur bei Kunden?
Falls letzters, dann ist halt die Frage, was auf deren System drauf ist und alle Dateien in kompatibler Version zu den Verweisen vorhanden sind- das ist nunmal die Voraussetzung für eine MDE.

Wieder mal ein Hinweis auf meinen ewig halbfertigen ReferenceChecker:
http://www.moss-soft.de/public/ReferenceChecker.zip

Ciao, Sascha

 

Wie beschrieben, entwickle ich manchmal auf 2000, manchmal auf 2003, manchmal auf 2007, manchmal neuerdings auf 2010. Will ich releasen, übertrage ich meine .mdb auf einen Rechner mit einer "sauberen" 2000-Installation und schreibe da die .mde. 2000 kann aus einem Word-10/11/12/14-Verweis nicht automatisch einen Word-9-Verweis machen, das mache ich also händisch. Bislang nie ein Problem, ...

Access hat unser Produkt in allen Konstellationen problemlos hochgefahren, was auch bedeutet, höhere Versionen als 2000 haben die Verweise erfolgreich nach oben angepasst, und auch die Registrierung unserer mitgelieferten ActiveX- bzw. DLL-Exoten hat bisher immer geklappt und dann nie zu Problemen geführt.

Das Problem mit der so erstellten .mde unter Access 2010 ist zuerst beim Kunden aufgetreten, mittlerweile habe ich aber auch auf 2010 umsteigen müssen, um mich mit solchem Krampf zu beschäftigen. (Bin ich eigentlich Entwickler und Supporter, oder zwingt mich Microsoft mittlerweile dazu, hauptamtlich Hausmeister / Admin zu sein? ;-) . (Geht nicht gegen die Admins, sondern im Gegenteil soll das ein empathisch gemeinter Scherz sein über deren schwierige Arbeitsbedingungen und deren geringe Anerkennung.)) Es treten noch weitere Probleme auch, auch mit einer .accde, mit denen werde ich mich zukünftig beschäftigen müssen. Das Reference issue ist mit dem Schreiben einer .accde behoben. Ich will aber nicht jedes Release bis zu 6fach (3 Sprachen derzeit, Tendenz steigend) ausliefern müssen, bloß wegen diesem Mist. Deshalb suche ich nach einer Lösung mit .mde.

Seh ich mir auch an, danke. Danke für deine ganzen Beiträge, die helfen mir bestimmt weiter.

mupan