Office: Warum sind TableDefs trotz Aufruf von Refresh nicht auf dem neuesten Stand?

Ich fasse noch einmal den Ablauf zusammen, damit sichergestellt ist, dass ich dich richtig verstehen.

Du importierst eine Excel-Datei in eine mdb-Datei (BE). Der Code läuft in einer anderen Access-Anwendung (FE).
Dazu öffnest du eine zusätzliche Access-Anwendungsinstanz und öffnest dort die BE-Datei mittels Opendatabase im nicht exklusiven Zugriff.
Anschließend schließt du die zusätzlich erstelle Anwendung und startest die Verknüpfung der zuvor importierten Tabelle im FE.

Kann es sein, dass die BE-Datei beim Schließen der Anwendung komprimiert wird und aus diesem Grund kein Zugriff möglich ist?
=> nächster Versuch: gar nicht über den Umweg eine zusätzliche Access-Instanz gehen, sondern nur die mdb öffnen.

statt:
Code:

schreibst du nur noch:
Code:

Weiters könntest du noch ausprobieren, was passiert, wenn du die zusätzliche Access-Instanz erst nach dem Verknüpfen schließt.

 

JosefP, Du hast es geschafft, jetzt läuft es *Smilie

Dein letzter Vorschlag hat den Durchbruch gebracht!

Wenn ich auf das explizite Öffnen einer Accessinstanz des Backends für den
Import verzichte und den Importcode vollständig im Frontend ablaufen lasse,
dann läuft das Programm ohne Fehlermeldung durch.

In den allgemeinen Access Optionen war komprimieren und reparieren beim Schliessen
nicht aktiviert, aber das war sicher eine gute Idee, man kann ja nie wissen.
Deine Zusammenfassung trifft genau auf den Kopf des Nagels. So ist es!

Der Importcode sieht jetzt so aus:
Code:

Ich habe mir von meinem Boss sagen lassen, daß die hier verwendeten
SQL Befehle für den Datentransfer zwischen verschiedenen Datenbanken
z.B. im MS SQL-Server Umfeld häufig angewandt werden. Aber da muß man
erst mal drauf kommen, das auch für Access Datenbanken so zu machen,
denn Microsoft schlägt in seiner Online Hilfe ja DoCmd.TransferDiesUndJenes
vor.

Ich danke euch allen für die anregende Diskussion, ich habe schon allein durch
diesen Thread viel neues gelernt!

P.S.

Aber warum funktioniert die ganze Importgeschichte nicht mit DoCmd.Transfer
und wieso gibt es den Seiteneffekt mit der "Bösen Liste", deren Datenherkunft
rein gar nichts mit der Importtabelle zu tun hat (bis auf den Speicherort, also
das Backend).

 

Man könnte ja sagen: Software ist wie Du oder ich - nicht ganz perfekt.

 

Mit der gezeigten DBEngine.Opendatabase-Variante kommt es auch zu einem Fehler?

Ein klein wenig haben sie schon miteinander zu tun: sie nutzen die gleiche mdb-Datei.

Hast du eigentlich schon einmal geprüft, ob die zusätzliche Access-Instanz überhaupt geschlossen wird bzw. hast du sie schon einmal sichtbar gemacht. Vielleicht kommt eine Meldung vor dem Schließen.

Code:

 

Auch die Variante mit
Code:

läuft ohne Fehlermeldung durch, funktioniert also auch.

Das Fenster der zusätzlichen Accessinstanz mit dem Backend wird kurz
sichtbar und dann deutlich erkennbar geschlossen, allerdings geht
das Meldungsfenster für den Fehler schon auf, bevor das Access Fenster
vollständig geschlossen ist. Aber dieses Timing hängt sicher auch mit dem
Nachleuchten des Bildschirms zusammen. Fakt ist, die zusätzliche Instanz
verschwindet nach dem Schließen im Programm vom Bildschirm.

 

Wenn du die Anwendungsinstanz bis nach dem Verknüpfen offen lässt, kommt es dann auch zum Fehler?

Eine weiterer Test wäre: mittels Msgbox warten, bis die Anwendungsinstanz auch aus dem Taskmanager (Prozess msaccess.exe) verschwunden ist. (Also nur noch ein msaccess.exe zu sehen ist.)

Zur Sicherheit noch einmal nachgefragt: "Beim Schließen komprimieren" ist aber nicht aktiv, oder?

mfg
Josef

 

Die Option "Beim Schließen komprimieren" ist nicht selektiert,
d.h. beim Schließen wird nicht komprimiert.

 

Sorry JosefP, diese Frage hatte ich vergessen zu beantworten:

Bevor ich hier nachgefragt habe, hatte ich das schon ausprobiert.
Ja, es kommt auch dann zum Fehler, wenn die zweite Accessinstanz
bis zum Schluß geöffnet bleibt, also erst nach der Verknüpfung
geschlossen wird.