Office: (Office 2003) access funktioniert nicht mehr

Hallo

von wo werden dies auf gerufen ? oder ist das AutoExec makro
sonst anders lösen
Wenn Autoexec kann evtl. Durch Start Formular ersetzt werden !
Wenn Normales Makro das nur Formolar öffnet ersetzen durch VBA-Code
lies meine Anhänge

 

\@Ruedi: "Makros konvertieren.pdf" hat frappierende Ähnlichkeit mit http://www.ardiman.de/datenbanken/gr...kros.html#SEC3 (der Wortlaut ist mindestens seit 7 Jahren so online) - ich find's gelinde gesagt frech, mich nicht einmal um Erlaubnis dieser aufgefrischten Veröffentlichung zu fragen. Abschnitt "Urheberschutz und Nutzung" von Impressum | www.ardiman.de wird als Lektüre empfohlen.

 

hallo

das ersetzen des makro hat nichts gebracht.
habe kein auto exec makro.

karl

 

hallo,

Habe weitere Erkenntnisse:
Wenn im formular ein bild dargestellt werden soll und das Formular als Startformular aktiviert wurde, dann gehen die datenbank-Dienstprogramme nicht.
Verwende folgenden Befehl:
Me.WM_Logo_B.Picture = Me.WM_Logo_Fahne
Deaktiviere ich diesen, dann funktioniert alles.

Beim normalen Bearbeiten merkt man über diesen Fehler nichts, aufgefallen ist dieses mir da ich Datenbank-Sichern wollte.

Muss ich einen anderen Befehl zum Anzeigen lassen in einen Startformular verwenden!

karl

 

Versuch's mal damit:
Code:

Zitat von FAQ 6.3 (Klick mich):

 

halo dirk

Es funktioniert auch mit den ! Zeichen nicht auch wenn ich ME ganz weglasse

karl

 

Hallo
verstehe ich nicht *frown.gif*
Arnne - hat doch nichts gesagt von Me weglassen odrt
Me!WM_Logo_B.Picture = Me!WM_Logo_Fahne

nur . durch ! ersetzen

 

hallo rudolf

habe auch bei #21 geschrieben das beides nicht funktioniert.

Ist es möglich über eine Modul beim starten ein bestimmten Bilderweiß zuordnen.

karl

 

Bei welchem Formularereignis wird die Bildquelle denn gesetzt?

Warum wird das Logo denn eigentlich verändert? Muss das unbedingt flexibel sein? Was passiert, wenn du probeweise den Code direkt mit dem Pfad versiehst:
Code:

Welcher Grafiktyp ist's denn (vermutlich läuft's mit BMP am besten)?

 

hallo Arne

Mit den Veränderten Verweiß probiert, ohne erfolg.
Me!WM_Logo_B.Picture = "d:\Logo_WM_2010.jpg"

Im Startformular habe ich unter Eigenschaften des Bildes den folgenden Befehl stehen: L:\Fahnen\Logo\WM-Weltkarte.jpg .
Hier wird beim öffnen eines Leeren Formulares dieses Bild dargestellt.
Wenn jetzt Daten das erste mal eingegen werden, so wird auch ein Logo für diese Eingabe gewählt. Ich benutze dieses hier an der Stelle, da in anderen Formular dann Verweiss auf den Pfad ist und in den geöffneten Formular dargestellt werden kann, Funktioniert ja auch.

Liegt der Fehler bei meiner Access installation habe Version 2003 bei einen Windows7 64bit.
Solltest Du keine 24bit Version haben, dann köntest zu Testzwecken vieleicht mal ein Formular erstellen, ein Bild einfügen und über einen Felderverweiss beim anzeigen, anzeigen lassen und als Startformular eingeben. und nach den Öffnen einmal Datenbank-Sicherung machen und mir das Ergebniss sagen.

mfg Karl

 

anbei mein Startformular

karl

 

Hallo nochmals an den Spezialisten

Ist es möglich das der Fehler nur bei 64bit Versionen auftritt !!
Habe die DB bei WinXP 32bit getestet, da funktioniert es einwandfrei.
DB windows7 64bit,Vista 64bit mit Access 2003 tritt der Fehler wieder auf.

Verträgt sich Access2003 mit einem BS 64bit nicht ?
Kann leider die DB nicht testen bei Windows7 oder Vista mit 32bit, hat jemand die möglichkeit !?

Installiert habe ich Windows7 Home 64bit, Accesss 2003 und Office 2007 Home, ist es auch möglch das sich das Office2007 mit Access2003 nicht vertragen !?

Karl

 

Ob es speziell mit Deinem Problem zu tun hat, kann ich nicht nachvollziehen. Aber es gibt einige Probleme unter 64-bit Systemen, es gibt viel Software die da enorme Schwierigkeiten/Laufprobleme hat.

Sehr oft liegt der Grund im Treiber-Zugriff die nicht wie bei 32 bit Systemen im Systemordner \system32 liegen sonder (zumindest unter Vista 64 bit) im Ordner \sysWOW64. Normalerweise leitet Windows Zugriffe auf den Systemordner System32 um, aber eben nicht immer und dann wird es problematisch beim Zugriff auf die Treiber.

Überprüfe mal im VBA-Editor alle Verweise auf den Zugriffspfad, hast Du hier noch Verweise auf Treiber aus dem Verzeichnis \system32 drinnen könnten die Probleme machen. Unter Acc2007 macht das zwar kein Problem da hier automatisch auf den passenden Ordner umgeleitet wird beim Zugriff, aber möglicherweise eben nicht bei Acc2003.

Ansonsten, würde ich an Deiner Stelle einfach eine neue leere DB erstellen und den Inhalt Deiner alten dorthin rüber kopieren und dort die Verweise neu setzen.

Danach müsste alles in der neuen DB problemlos funktionieren.

Gruß

Rainer

 

\@Rainer:

Hattest du damit schon einmal Probleme?

In den Verweisen ist doch im Prinzip nur die GUID der Bibliothek gespeichert und der Rest wird dann über die Registry eingelesen, oder? Wenn du z. B. eine COM-dll an einen anderen Ort kopiert und dort neu registrierst, müsste der Verweis in Access auf den neuen Speicherort zeigen.
Es wäre schlimm, wenn in den Verweisen der Pfad gespeichert würde, da man dann für jedes Systemkonfiguration eine extra mde erstellen müsste.

Ein Problem sollte eigentlich nur dann auftreten, wenn die 64-bit-Version der COM-dll die gleiche GUID wie die 32-bit-Version verwendet.

mfg
Josef

 

\@Josef:

Nein. Beides wird gespeichert.
Im VBA-Projekt wird jeweils zu einem Verweis folgendes abgespeichert - quasi ein "Verweisdatensatz":
- Art des Verweises (COM; Dokument-Datei - unter Access md*; .vba-Datei)
- GUID
- COM-Versionsnummer (...zu einer Lib-GUID kann es mehrere Versionen geben!)
- LCID (also Sprache; spielt aber keine Rolle)
- Dateipfad

Was VBA beim Einlesen dieser Daten dann macht, ist eine andere Frage.
Ich gehe ebenfalls davon aus, dass erstmal nur die GUID verwendet wird, und wenn in der Registry dort die Typelib eingetragen ist, scheint alles ok zu sein.
Aber: VBA meckert auch nicht, wenn die Typelib in der Reg. NICHT vorhanden ist, dafür aber der Pfad stimmt!
Nachweis: Eine COM-DLL in die Verweis aufnehmen, DB schließen, DLL deregistreren (ggfls. in HKCR/Typelib checken, ob sie dort weg ist), DB wieder öffnen: Verweis ist da und nicht als Broken gekennzeichnet.
Auch im Objektkatalog wird diese Lib korrekt angezeigt und man kann VBA-Routinen mit deren Klassen anlegen und erfolgreich kompilieren. Erst bei Ausführung kommt die Meldung "Objekterstellung nicht möglich".
Heißt: Selbst der Compiler braucht die Registry nicht, sondern lädt die TypeLibrary per LoadTypeLibEx(Dateiname), um die VTable-Entries in das Kompilat zu schreiben.
(VBA registriert die DLL übrigens auch nicht selbständig, wie andernorts manchmal zu lesen is - dazu müsste Access ja als Admin ausgeführt werden.)

Erst, wenn GUID und Dateipfad nicht stimmen, meldet Access einen Verweisfehler beim Öffnen des VBA-Editors (A2003) bzw. schon beim Öffnen der ACCDB (A2007 ff.).

@all:
Büdde, büdde nicht immer mit den Verweisen und ähnlichen Voschlägen kommen, wenn eine DB abstürzt. Es gibt praktisch keine Abstürze durch Verweisprobleme! (Auch die Runtime stürzt bei Verweisproblemen nicht ab, sondern beendet sich ordnungsgemäß mit de Meldung "Ich schließé jetzt.")
Der absolut einzige Fall für Absturz bei inkorrekter Komponente ist der, dass die im Dateisystem vorhandene die gleiche TypeLib-GUID hat, wie sie im VBA-Projekt gespeichert ist, aber tatsächlich so modifiziert wurde, dass die VTables nicht mehr übereinstimmen. Dann kann es zu falschen Einsprungspunkten kommen.
Aber das passierte mir bisher ausschließlich bei selbst erstellten COM-DLLs, die ich geändert und neu kompiliert hatte, aber COM-Kompatibilität (=gleiche CLSIDs) beibehielt. In diesem einen Fall muss die MDB dann dekompiliert werden bzw.: Verweis raus und wieder rein geht auch - das entspricht einem immanenten Dekompilieren.

@Karl:
Hast du mal Arnes Hinweis verfolgt und statt des JPGs eine BMP-Datei für das Bild verwendet?
Mir hört sich das Ganze nämlich eher nach einem Problem mit den Office-Grafikfiltern an. Und die sind sind sehr absturzfreudig. *wink.gif*

Ciao, Sascha