Hallo,
ich arbeite mit zwei verschiedenen Office-Versionen (zwei Rechner) und jedesmal wenn ich mit dem Office 14 die DB starte, gehen mir die zwei Verweise von Excel und Outlook verloren. Office 16 überschreibt Excel und Outlook 14.0 Object Library mit 16 und beim öffnen von Office 14 steht unter Verweise das die Excel und Outlook 16.0 Object Library nicht vorhanden sind.
Frage:
Gibt es eine Möglichkeit per VBA abzufragen welche Office Version gerade die Access DB gestartet hat und dementsprechend den richtigen Verweis (Excel und Outlook 14.0 oder 16.0) zu setzen?
Ich weiß man kann es auch per Hand ändern, aber das nervt mit der Zeit. Wäre für jede Idee sehr dankbar!
Gruss
Ken
Normalerweise sollten die Verweise doch nach dem ersten händischen ändern erhalten bleiben.
Kopierst du die Anwendung immer zwischen den Rechnern hin und her, oder verwendest du die DB auf einem portablen Speicher?
Grundsätzlich wird empfohlen Late Binding zu verwenden, sofern der Code das zulässt. Hast du diese Option schon erwogen?
LG Markus
Die Anwendung ist auf einem Server, also nicht auf einem der beiden Rechnern. Wenn 14.0 "aktiviert" ist und ich mit Office 16 arbeite, stellt Access es automatisch auf 16.0 um, aber leider nicht auf 14.0 wenn ich dann mit dem anderen Rechner das Programm starte.
Nachmal mein Nachtrag von vorhin.
Grundsätzlich wird empfohlen Late Binding zu verwenden, sofern der Code das zulässt. Hast du diese Option schon erwogen?
LG Markus
Sorry deine letzte Frage habe ich übersehen.
Nein Late Binding habe ich nicht verwendet. Da müsste ich mich dann einlesen wenn du sagst damit lässt sich das Problem lösen.
Offensichtlich ist die DB nicht in Front- und Backend aufgeteilt.
Ich meine, damit wäre das Problem auch gelöst. Dann hat halt jeder Rechner sein Frontend und nur die Daten bleiben am Server. Bei einer Änderung im Frontend hast natürlich wieder etwas mehr Arbeit.
LG Markus
Richtig, sie ist nicht aufgeteilt.
Habe gerade mal nachgelesen...für Late Binding braucht es nicht viel Änderungen wenn ich das richtig verstanden habe:
z.B.
Dim xlApp As Object statt Excel.Application
Dim xlSheet As Object statt Excel.Worksheet
Ich dachte mir nur, dass vielleicht noch jemand so ein Problem hat und statt den gesamten Code umzuschreiben eine Abfrage welche Version und dementsprechen die Verweise zu setzen etc. einfacher wäre.
Hallo Ken,
Abgesehen von Markus' Hinweis bezügl. FE/BE Trennung, kannst du die Verweise
über die Application.References auslesen und setzen.
gruss ekkehard
Zitat von: Ken am Oktober 18, 2016, 18:48:33
Ich dachte mir nur, dass vielleicht noch jemand so ein Problem hat und statt den gesamten Code umzuschreiben eine Abfrage welche Version und dementsprechen die Verweise zu setzen etc. einfacher wäre.
Vom Prinzip her natürlich möglich, solange man keine accde Version einsetzt.
Habs aber selbst so nicht im Einsatz.
Die Schritte die mMn nötig sind.
1. Alle betroffenen Verweise werden erst zur Laufzeit gesetzt und zum Programmende wieder gelöscht.
2. das automatische kompilieren zum Programmstart muss deaktiviert sein.
Beide Punkte führen ansonsten zu einer Lawine an Fehlermeldungen.
Zu beiden Themen findest du im Web Infos, oder andere können dir da weiterhelfen.
Sollte das Programm abstürzen, und du dadurch die Verweise nicht löschen kannst, hast halt die Fehlermeldungen.
LG Markus
Danke, ich werde es mal mit Late Binding versuchen.
Gruss Ken
Hallo,
mit dem Einsatz von Late Binding bist du auf Dauer unabhängig von der Office-Version und vielleicht möchtest du das Programm ja auch noch in fünf Jahren oder mehr nutzen. Da es sich mit Excel und Outlook ja ebenfalls um Office-Produkte handelt, ist dies auch kein großer Akt, die Objektkataloge sind ja verfügbar, die Methoden und Eigenschaften der Objekte müssen nicht mühsam erforscht werden.
Es ist dabei durchaus empfehlenswert, den diesbezüglichen Code mit Early Binding zu erstellen und erst wenn alles fertig und ausgetestet ist, auf Late Binding umzustellen. Zu beachten ist dabei nur noch, dass etwaige Konstanten nicht verfügbar sind und innerhalb der Access-Anwendung deklariert werden müssen - was ich für sinnvoller halte als Direktwerte zu verwenden, die keiner versteht.
PS:1. Alle betroffenen Verweise werden erst zur Laufzeit gesetzt und zum Programmende wieder gelöscht.Das muss nicht zwingend so sein, man kann sie prüfen und nur bei Bedarf handeln. Dazu kann man die jeweils vorhandene Office-Version aus der Registry auslesen. Insgesamt ist der Programmieraufwand, sofern Neuland, nicht unerheblich und wie gesagt nicht unbedingt (je nach Vorgehensweise) etwas für die Ewigkeit.
Ich dachte nur es wäre kein grosser Aufwand, weil ich ein "Stück Code" im Netz gefunden habe, wo die Microsoft Office 14.0 oder 16.0 Object Library automatisch angepasst werden. Das funktioniert sehr gut...nur halt nicht mit Excel bzw. Outlook 14.0 bzw. 16.0
Aber ich habe wieder etwas dazu gelernt. Danke an alle die mir bei diesem Thema geholfen haben.
Zeig doch bitte mal den Code, der sollte sich doch leicht anpassen lassen.
Hab ihn jetzt nicht hier...morgen setze ich ihn hier ein.
@MaggieMay,
das Löschen der Verweise deshalb, weil fehlende Verweise im Gegensatz zu nicht vorhandenen Verweisen zu nicht abfangbaren Fehlern führen.
Wie könnte also dieses Handeln bei Bedarf aussehen, ohne dass es zu einer Fehlermeldung kommt?
Falls du da eine Lösung kennst, bitte ich darum. Das Prinzip in Stichworten reicht.
LG Markus
Hallo!
[eventuell etwas OT / Entwickeln mit unterschiedlichen Access-Versionen]
Von einer ähnlichen Lästigkeit kann ich berichten. ;)
Ich muss hin und wieder eine Anwendung mit Access 2016 weiterentwickeln, die aber hauptsächlich mit Access 2010 genutzt wird. Die accde erstelle ich natürlich mit Access 2010.
Zur Entwicklungszeit verwende ich gerne Early Binding - also sind die Verweise in der Anwendung eingestellt. Öffne ich die accdb mit Access 2016 wird ohne Probleme von den Office 2010-Verweisen (Excel, Word, ..) auf die 2016er-Version geändert.
Öffne ich später die accdb wieder mit Access 2010 passen die Verweise nicht mehr. Korrigieren kann man diese nur durch Löschen und erneutem Einbinden.
Da das manuelle Löschen und erneute Einbinden mit dem Verweisdialog umständlich ist, eine Variante, die etwas schneller zum Ziel führt:
- GUID der defekten Verweise ermitteln (Kann man per Code durchlaufen oder man kennt die GUIDs für Word & Co.
- Verweise manuell löschen (Application.References.Remove funktioniert bei defekten Verweisen leider nicht)
- Verweise per Code wieder einbinden (siehe Code)
Einbinden von Verweisen:
Application.References.AddFromGuid "GUID-String des Verweises", 0, 0
Die Parameter Major und Minor auf 0 einstellen, dann muss man sich beim Code nicht um die benötigte Version kümmern. (Anm.: GUID für Word, Excel und Co. ist von Office 2016 und 2010 identisch.)
mfg
Josef
Danke Josef, was würden wir nur ohne dich tun?
Kann man sich auf diese Parameter Major und Minor verlassen, oder hattest du da auch schon Probleme?
Bei einer accde kann ich die Verweise ja nicht ändern.
Late Binding schön und gut, aber ich nutzt halt oft Events von COM Klassen.
LG Markus
Hallo,
ZitatWie könnte also dieses Handeln bei Bedarf aussehen, ohne dass es zu einer Fehlermeldung kommt?
der Trick dabei ist, dass du in den - möglichst in ein separates Modul verpackten - beim DB-Start auszuführenden Prozeduren die dort benutzten Funktionen qualifiziert ansprichst, bspw. mit "VBA.Left", dann werden sie auch gefunden und der zur Prüfung und Reparatur benötigte Code kann problemlos durchlaufen.
PS:
ZitatVerweise manuell löschen (Application.References.Remove funktioniert bei defekten Verweisen leider nicht)
Da habe ich aber andere Erfahrungen gemacht - wovon mag das abhängen?
@Markus:
Bei einer ACCDE funktioniert die Reparatur natürlich nicht - leider.
@Markus:
Ich nutze das nur für die Office-Anwendungen (Word, Excel und Outlook). Bei diesen Verweisen funktionierte das mit Guid + 0 für Major und Minor. (Falls Interesse besteht, kann ich das VB-Script zum Download bereitstellen, mit dem ich meine Entwickler-Version korrigiere.)
Bezüglich accde:
Da das Ändern der Verweise nicht möglich ist, kannst du nur versuchen, die accde mit der niedrigsten Version erstellen, und hoffen, dass die Abwärtskompatiblität erhalten bleibt.
Falls du nicht zu viele Events benötigst, könntest du diese auch bei Late-Binding verwenden. Ist aber viel umständlicher zu programmieren als über eingebundene tlb/dll-Verweise.
(Das zu beschreiben weicht aber zu sehr vom Thread-Thema ab.)
@MaggieMay
ZitatZitatVerweise manuell löschen (Application.References.Remove funktioniert bei defekten Verweisen leider nicht)
Da habe ich aber andere Erfahrungen gemacht - wovon mag das abhängen?
Bei mir kommt unter Access 2010: Runtime error '48': Error in loading DLL
Funktioniert bei dir das Entfernen eines defekten Word-2016-Verweises, wenn auf dem PC ein Word 2010 installiert ist?
LG
Josef
Hi,
ZitatLate Binding schön und gut, aber ich nutzt halt oft Events von COM Klassen.
das Thema dieses Threads ist aber ein anderes...
@MaggieMay
hier ist wie versprochen der Code (aus dem Netz, nicht von mir!)
Function CheckRefs()
Dim db As Database, rs As RecordsetDim x
Set db = CurrentDb
On Error Resume Next
'Stop
' Führt die Abfrage TestVerweise aus,um das Auftreten des Fehlers
' zu testen
Set rs = db.OpenRecordset("TestVerweise", dbOpenDynaset)
x = rs!ausdr1
' Wenn Sie nun den Fehler 3075 sehen, informieren Sie die
' Benutzer, daß Sie die Anwendung bearbeiten müssen.
' Fehler 3075 steht für folgende Meldung:
' "Funktion steht in Ausdrücken nicht zur Verfügung"
If Err.Number = 3075 Then
MsgBox "Diese Anwendung hat neuere Versionen " _
& "benötigter Dateien auf Ihrem Computer entdeckt. " _
& "Es kann einige Minuten dauern, Ihre Anwendung " _
& "erneut zu kompilieren."
Err.Clear
FixUpRefs
End If
End Function
Sub FixUpRefs()
Dim r As Reference, r1 As Reference
Dim s As String
' Sucht die erste Referenz in der Datenbank, die weder
' Access noch Visual Basic for Aplications ist.
For Each r In Application.References
If r.Name <> "Access" And r.Name <> "VBA" Then
Set r1 = r
Exit For
End If
Next
s = r1.FullPath
' Entfernt den Verweis und setzt ihn wieder ein.
References.Remove r1
References.AddFromFile s
' Ruft einen versteckten SysCmd-Befehl auf, um alle Moduleder
' Datenbank zu kompilieren bzw. zu speichern.
Call SysCmd(504, 16483)
End Sub
Zitat von: Josef P. am Oktober 18, 2016, 22:28:51
@Markus:
Ich nutze das nur für die Office-Anwendungen (Word, Excel und Outlook). Bei diesen Verweisen funktionierte das mit Guid + 0 für Major und Minor. (Falls Interesse besteht, kann ich das VB-Script zum Download bereitstellen, mit dem ich meine Entwickler-Version korrigiere.)
Ich schau mir immer gerne Code von Profis an, ansonsten schreibe ich ihn lieber selber - der TS könnte ihn ja auch gut gebrauchen.
Wenn ich das jetzt richtig verstanden habe, ist Late Binding im Bereich Office absolut überflüssig und kontraproduktiv?
Oder gibt es dennoch Gründe die dafür sprechen?
LG Markus
Hallo!
Mein Script zum Reparieren der Office-Verweise in der accdb/mdb: RepairReferences.vbs (http://access.joposol.com/download/RepairReferences.vbs.txt)
Das Script hilft natürlich nur dem Entwickler während der Anwendungserstellung. Für die Anwender ist das nicht brauchbar.
Ich verwende das Script per Drag&Drop - also einfach die zu reparierende accdb/mdb über die Script-Datei schieben. Alternativ kann man auch nur das Script starten, dann kommt eine Auswahldialog um die Access-Datei auszuwählen.
[OT]
ZitatWenn ich das jetzt richtig verstanden habe, ist Late Binding im Bereich Office absolut überflüssig und kontraproduktiv?
Oder gibt es dennoch Gründe die dafür sprechen?
Wenn ich Early-Binding nicht benötige, bevorzuge ich Late-Binding (bei der Anwendungsauslieferung), da dadurch kein Nachteil entsteht und die Anwendung auch läuft, falls einmal kein Word o. ä. installiert ist. Dann kracht es zwar trotzdem bei CreateObject("Word.Application"), aber der Rest der Anwendung läuft.
Wenn ich aber davon ausgehen kann, dass alle Anwender eine identische Software-Installation haben (was bei meinen Kunden durchaus ausreichend gegeben ist), sehe ich Early Binding nicht so kritisch. Ich bin sogar dagegen, dass man Late Binding als Paradigma betrachtet. Es hängt einfach vom jeweiligen Anwendungsfall ab, was im sinnvollsten ist.
Wenn man sich natürlich mit Early Binding Fehler einfängt, war es die falsche Wahl. ;)
LG
Josef
Hi,
ZitatWenn ich das jetzt richtig verstanden habe, ist Late Binding im Bereich Office absolut überflüssig und kontraproduktiv?
ich sehe das genau umgekehrt, gute Gründe dafür wurden bereits mehrfach genannt.
Gerade bei Office-Programmen würde ich (in der Auslieferungsversion einer Anwendung) Late-Binding einsetzen, da hiermit keine Probleme zu erwarten sind. Selbst wenn der Anwender eine benötigte Komponente nicht installiert hat (
und dementsprechend auf die jeweilige Funktionalität verzichten muss), ist das auf diese Weise noch am ehesten behandelbar.
Dass eine einheitliche Systemumgebung vorhanden ist, kann man wohl eher selten voraussetzen.
@Maggie, danke für deine Argumente.
@Josef, mit VB Script habe ich mich noch nicht beschäftigt. Bei Zeiten werde ich das aber.
Was mich mehr interessiert, Events bei Late Binding. Wie geht das.
@Ken, hast du die Lösung von Josef - lediglich den Verweis zu verändern - verstanden?