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

Nein, ich war von der Einbindung der fraglichen Tabelle ausgegangen.

Das wars dann wohl nicht. "Streichen Sie das". *Smilie

 

Na immerhin. Somit läuft die Funktion dann ja erstmal. ^^

Wobei ... bist Du Dir wirklich sicher das die Datensatzherkunft des Listfeldes nicht irgendwie/irgendwo einen Zugriff auf die Import-Tabelle nimmt?

Haben diese 3 Felder vllt. in irgendeiner Art und Weise einen Zusammenhang mit der Datensatzherkunft der ListBox?

Vielleicht nicht direkt, aber möglicherweise indirekt? Beinhaltet die ListBox vllt Werte aus einer Abfrage und die Abfrage bezieht berechnete Felder oder Sub-Selects auf die Import-Tabelle, bzw. auf diese 3 Felder?

Gruß

Rainer

 

Hallo Rainer,

ich zeige dir mal die Datenherkunft der Liste:

Code:

tblDatei ist nur eine Tabelle im Backend, in die vor jedem Import ein
Datensatz eingefügt wird. Das findet im Aufruf der Funktion GetNeueDateiID
im wenige Beiträge vorher angegebenen Quellcode statt. In dieser
Datenherkunft taucht keine weitere Abfrage auf.

 

Banale Frage: Wie sieht es denn aus, wenn die Datenherkunft erst nach dem erfolgten (und erfolgreichen) Import ergänzt wird, also quasi Realität hergestellt wird?

 

Das Formular, auf dem diese Liste erscheint, soll direkt nach dem Start in
dieser Liste die bereits importierten Dateien anzeigen. Der Benutzer soll
entscheiden können, ob er eine neue Datei importiert oder eine der bereits
eingelesenen Tabellen durch Doppelklick auf den entsprechenden Eintrag
der Problemliste in einem anderen Formular bearbeitet (d.h. in den
nachträglich angefügten Spalten seine Häkchen macht).

Deswegen soll die Liste eigentlich immer etwas anzeigen und nie leer sein.
Der auch schon von Raist10 vorgeschlagene Trick geht eigentlich nur im
äußersten Notfall als Übergangslösung, bis entweder eine richtige Lösung
oder ein unauffälligeres WorkAround gefunden wurde.

Wen würde es nicht verwirren, wenn die zunächst gefüllte Liste beim Import
zwischendurch geleert und dann wieder mit den selben Daten gefüllt wird?

 

In solchen Fällen hilft Application.Echo False gut weiter. *wink.gif*

Unauffälliger und ohne Echo False wäre wenn Du das Listenfeld nicht an eine Abfrage/Tabelle bindest sondern als Wertliste gestaltest.

Das sollte das Problem zuverlässig vermeiden und man braucht auch keine kleinen schmutzigen Tricksereien. *wink.gif*

Ich nehme ja immer noch an das irgendwo durch die Bindung des Listbox an eine Abfrage ein Zirkelbezug entsteht oder sowas in der Richtung, einfüllen der Daten als Wertliste würden mit hoher Sicherheit keinen zirkelbezug auslösen .... wenn doch, dann kannst Du zumindest ganz exakt den Übeltäter lokalisieren (immer ein Datenfeld nach dem anderen einfügen und sehen was passiert).

Gruß

Rainer

 

Application.Echo False *mrcool

Super, ist zwar nicht schön, aber es wirkt.
Ja ja, die Grabbelkiste mit den Tricks sollte immer bereit stehen *wink.gif*

Deine Anregung bezüglich irgendwelcher Zirkelbezüge laß ich mir noch mal durch
den Kopf gehen. Vielleicht finde sich das Teufelchen ja doch noch dank Eurer Hilfe.

Danke für die vielen Hinweise.

 

Eines könntest du noch ausprobieren, um die Fehlerquelle einzuschränken:
Was passiert, wenn du auf TransferSpreadsheet verzichtest und die Tabelle per SQL-Anweisung (Insert into) erstellst?
Wird anschließend die Tabelle auch nicht gefunden?

zu Application.Echo False:
Es geht auch eine Spur weniger brutal: Form.Painting = False ... damit wird nur das Neuzeichnen des Formulars verhindert.

mfg
Josef

 

O.K. JosefP,

ich habe INSERT INTO probiert, und zwar zunächst zum Üben
mit einer Abfrage nach folgendem Schema:

Code:

Access meint dazu: Installierbares ISAM nicht gefunden!

Die Syntax dürfte korrekt sein, d.h. ich bekomme mit diesem Schema keine
Meldung mehr über einen Syntaxfehler und laut Online Hilfe für die In Klausel
müßte es so gehen.
Meine Registry enthält Einträge für die **Excel**.dll's die sich auch jeweils in
dem eingetragenen Verzeichnis befinden.
Die diversen Docmd.TransferIrgendwas haben bisher immer funktioniert und
der Import/Export Assistent hat auch immer ohne Fehlermeldung funktioniert.

 

Wie kommst du auf diese Zeile?

Versuche es einmal auf diese Art:
Code:

Bei mir funktionieren sie auch. Daher dachte ich, es könnte bei der Suche nach der Fehlerquelle helfen, wenn du einmal den Import durch eine anderen Methode ersetzt. Wenn dann der Fehler immer noch auftritt, liegt es nicht an TransferSpreadsheet. Ein Ausschlussprinzip ist doch ein ganz normales Vorgehen für eine Fehlersuche, oder?

 

Lieber JosefP,

deine Variante des SELECT ... INTO funktioniert auch bei mir
(allerdings hast Du weiter oben selbst INSERT INTO vorgeschlagen und SELECT INTO gemeint *wink.gif* ),
aber die Funktion TabellenVerknuepfungErzeugen scheitert immer noch an
der selben Stelle, also bei TableDefs.Append.

Also dein Vorschlag
Code:

funktioniert, löst aber leider das Problem nicht.

P.S.

Entschuldige bitte, falls mein letzter Beitrag bei dir den Eindruck erweckt hat
als ob ich mich über irgend etwas beschweren wollte. Das ist nicht der Fall.

Ich danke dir (und natürlich auch allen anderen) ausdrücklich für deine
konstruktiven Vorschläge.

Eigentlich probiere ich gern etwas neues aus. Da ich aber bisher noch gar
keine Erfahrung mit der Konstruktion von SQL-Befehlen für den Datentransfer
zwischen verschiedenen Datenbanken habe, habe ich mich an der Online
Hilfe von zu Access SQL orientiert und so ist der oben angegebene und
wahrscheinlich nicht korrekte INSERT ... INTO Befehl zustande gekommen.

Die von Access ausgegebene Fehlermeldung
Installierbarer ISAM Treiber nicht gefunden
ist für mich total irreführend!

 

Naja, ich schreib halt nicht immer einen fertig verwendbaren Code. *Smilie
MIt dem Select-Beispiel wollte ich dir nur zeigen, wie ich den ODBC-Teil eingeben würde.

funktioniert, löst aber leider das Problem nicht.

Also kommt es auch bei dieser Variante zur Meldung, dass die Tabelle nicht vorhanden ist?

Kannst du nun mit diesem Code bitte noch folgendes testen:
Code:

mfg
Josef

 

Hallo JosefP

ich habe den relevanten Code nach deinem Vorschlag wie folgt geändert:
Code:

Die MessageBox zeigt den Namen der gesuchten Tabelle an!

Nochmal vorsichtshalber zur Orientierung:

Das Problem besteht im Moment allerdings nicht darin, daß die TableDef
der Importierten Tabelle gemäß db.TableDefs(strTrgTblName) nicht gefunden
wird, sondern es hat sich in die Funktion TabellenVerknupfungErzeugen
Code:

verlagert. Mit dieser Funktion wird die importierte Tabelle aus dem Backend
ins Frontend verknüpft. Und hier wird nach meiner Interpretation der Fehlermeldung

Laufzeitfehler 3011:
Das Microsoft-Jet-Datenbankmodul konnte das Objekt tblImport_XY nicht
finden. Stellen Sie sicher, dass das Objekt exisiert und dass die Namens und
Pfadangaben richtig eingegeben wurden.


die erfolgreich importierte und vom Backend ins Frontend zu verknüpfende
Tabelle tblImport_XY nicht gefunden.

 

hmmm ... ich dachte das Problem war ursprünglich, dass ein TableDef nicht gefunden wurde.

BTW: schau dir meinen Code noch einmal genau an, da sind 2 Punkte enthalten, die ich durchaus mit Absicht rein schrieb. *wink.gif*

 

Sorry JosefP,

im Eifer des Gefechts habe ich wohl etwas übersehen.

Ich habe jetzt deinen Vorschlag wie folgt umgesetzt:
Code:

Das ändert leider nichts. Der Import läuft mit dem gezeigten Code problemlos.
Aber später beim Verknüpfen wird die erfolgreich importierte Tabelle nicht gefunden.