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

\@hcscherzer, ich habe als erstes nur an die Variablen gedacht, aber die Schleife ansehen wäre sicher auch wichtig gewesen *wink.gif* Wieder was gelernt heute...

 

Noch ein paar Anmerkungen zum Code aus Beitrag #1 (unabhängig davon, ob es eine bessere Importvariante gibt):
Im Prinzip sollte die Prozedur ImportiereUndManipuliereExcelDaten (zumindest bis zur Property-Erstellung) funktionieren. (Auf das Problem bei der Prozedur GetTblDef hatte Hans-Christian schon hingewiesen.)

Ein paar Auffälligkeiten:
Wo sind denn die Variablen db, tdf, fld, und accObj deklariert?
Zur Sicherheit: ein On Error Resume next ist während der Code-Ausführung aber nicht aktiv, oder?

Eigentlich ist aber das 2. Öffnen der DB umsonst - du könntest auch gleich mit der einen Access-Instanz die Eigenschaft einfügen.

Das TblDef-Objekt suchen ist meiner Ansicht nach auch umsonst. Wenn die Tabelle zuvor ohne Fehler erstellt wurde, dann wird sie schon vorhanden sein. *wink.gif*

mfg
Josef

 

\@Frank: Einer verlinkten Tabelle kann man aber kein zusätzliches Auswahlfeld hinzufügen (und das ist ja wohl der eigentliche Wunsch und somit Hauptkriegsschauplatz), nur dem Original (eben der Tabellendefinition).

Im Temp-BE wäre der Effekt des Nichterkennens der Tabelle der gleiche wie im echten BE.

Ansonsten: Vielleicht ist die TransferSpeadsheet-Anweisung bei großen Tabellen doch nicht ganz synchron und man schiebt vor der Inanspruchnahme der Tabelle eine Pause ein (Sleep 5000).

 

Hallo,
ich habe das Thema nur überflogen, aber
Code:

statt Code:

sollte das Problem evtl. lösen.

Gruß Mike

 

Hallo Allerseits,

vielen Dank für eure Aufmerksamkeit *top und Lösungsvorschläge.

Es wurde spekuliert, ob die beiden Varianten der For Each Schleife, also

Code:

nach dem Verlassen der Schleife durch Exit For unterschiedliche Ergebnisse
für das gesuchte TableDef Objekt liefern könnten. Ich habe es ausprobiert
und festgestellt das beide Varianten ins Leere laufen, d.h. die gesuchte
TableDef wird nicht gefunden, obwohl sie da sein muß!

Das die Funktionsparameter bei der Übergabe korrekt initialisiert sind kann
ich im Lokalfenster des VBA-Editors nachvollziehen.

Auf die Suche nach dem TableDef Objekt kann ich nicht verzichten, weil
ich ja einige Spalten an die importierte Tabelle anhängen will.

Aber ich glaube Josef P. meint folgendes:
Das von mir bereits erstellte Application Object enthält natürlich eine
CurrentDB und diese kann ich nutzen für das was ich vorhabe (TableDefs.Refresh
ist da ja schon mit drin). Also kann ich mir das schliessen des Application Objektes
sparen und gleich damit weitermachen. Und die Suche dürfte überflüssig sein, weil
Currentdb.TableDefs("GesuchteTabelle") das TabelDef Objekt liefern müsste,
wenn es denn schon vorhanden ist.

O.K. habe ich verstanden und ausprobiert. Ergebnis: Leider negativ,
das gesuchte TableDef Objekt wird nicht gefunden *entsetzt

Das war trotzdem ein nützlicher Hinweis, denn dadurch wird der Code besser!
Bei den vielen Möglichkeiten die Access bietet, sehe ich manchmal den Wald vor
lauter Bäumen nicht mehr.

Die Idee mit der Sleep Funktion
Code:

mit 1000 bis 5000 msec war mein erster Ansatz bevor ich hier
nachgefragt habe. Das hat leider nichts gebracht! Die Tabellen mit denen ich
im Moment den Code teste umfassen einige hundert Excel Zeilen mit
etwa 15 Spalten. Das eingelesene Datenvolumen ist bisher also viel kleiner als
das was die verehrte Kundschaft voraussichtlich mit dem Programm verarbeiten will.

So wie ich das sehe, ist das Problem noch nicht gelöst!

Weitere Denkanstöße von eurer Seite sind mir sehr willkommen
und vielen Dank bis hierhin.

 

Hast Du schonmal probiert zu diesem Zeitpunkt ein SQL-Statement auf die importierte Tabelle auszuführen, z.B. mit xxxxx.execute strSQL, dbFailOnError?

Würde das denn funktioniere oder bekommst Du hier auch einen Fehler und wenn ja welche?

Schonmal probiert vor der Abfrage der TableDef ein DoEvents einzubauen, könnte hier eher helfen als ein Sleep ... bei Sleep "schläft" die Application komplett und macht danach an gleicher Stelle weiter, bei DoEvents werden erstmal alle anstehenden Anweisungen zu Ende ausgeführt bevor mit dem Code weiter gemacht wird.

Könnte mir vorstellen das das Problem damit zusammen hängt das die Verarbeitung der importierten Tabelle im Hintergrund noch nicht abgeschlossen ist, physisch vorhanden aber noch nicht in der Objektauflistung angekommen.

Vielleicht könnte ja auch eine Schleife helfen die bei leerem Suchergebnis erst ein DoEvents auslöst und dann nochmal von vorne nach der TableDef sucht (sollte aber vllt auf z.B. 10 Durchläufe begrenzt sein).

Gruß

Rainer

 

Vielleicht hilft auch ein accObj.DBEngine.Idle dbRefreshCache. Daran sollte es meiner Ansicht nach aber nicht liegen. Ich vermute eher, dass sich da noch ein anderer Fehler im Code versteckt.

@EinRadler: kannst du eine kleine Beispiel-Anwendung erstellen, mit der das Problem nachgestellt werden kann?

mfg
Josef

 

Hallo, da bin ich wieder.

Nachdem ich eine Testanwendung zusammengestellt hatte, um diese an JosefP zu
schicken, mußte ich mit großem Erstaunen feststellen, dass diese fehlerlos
funktioniert. Also habe ich das Programm nicht verschickt, denn das nützt
ja nichts, wenn der Fehler darin nicht auftritt.

Der Unterschied zu dem Programm mit dem geschilderten Problem besteht
darin, dass ein Listenfeld, ein Textfeld und zwei Labels weniger auf dem
bisher einzigen Formular der Anwendung verblieben sind. Das weggelassene
Listenfeld zeigt die bereits importierten Tabellen an.

Wenn ich in dem Originalformular nur die Datenherkunft des fraglichen
Listenfeldes leer lasse, dann läuft jeder Importvorgang ohne Fehlermeldung
durch. Diese Datenherkunft ist eine verknüpfte Tabelle im Backend, in der
alle Importvorgänge protokolliert werden und die vor dem Start des Imports,
d.h. unmittelbar vor dem Öffnen von accObj und damit vor dem Aufruf von
accObj.DoCmd.TransferSpreadsheet, durch einen neuen Datensatz aktualisiert
wird.

Durch eure Anregungen bin ich auf jeden Fall dazu gebracht worden an Ecken
zu suchen, die ich bisher noch gar nicht in die Fehlersuche mit einbezogen
habe. Das die Datenherkunft des Listenfeldes einen Schlüssel zum Verständnis
liefert, hätte ich jedenfalls anders nicht bemerkt.

@JosefP
Noch habe ich den Fehler nicht identifiziert, falls Du mir helfen willst, kann
ich dir gerne die schon vorbereitete und funktionierende Testanwendung schicken.
Vielleicht kannst Du dann durch Hinzufügen eines Listenfeldes und Definition
der Datenherkunft das Problem nachvollziehen.

 

Hallo!

Die Datenherkunft des Listenfeldes hat aber nichts mit der importierten Tabelle zu tun, oder?

Bezüglich Testanwendung: du kannst die Datei auch hier (gezippt) im Forum online stellen, dann können mehrere interessierte versuchen das Problem nachzustellen.

mfg
Josef

 

Hallo, liebe Leute

Die Datenherkunft des Listenfeldes und die importierte Tabelle sind verschieden.
Ich nenne die Datenherkunft des Listenfeldes hier mal tblDatei
und die importierte Tablle im Backend tblImport_ID. Dann wird der Tabelle
tblDatei zunächst ein neuer Datensatz mit dem Schlüssel ID hinzugefügt
und erst im Anschluß daran wird die Excel Tabelle in die neue Import Tabelle
tblImport_ID geschrieben.

Wenn mein Boss grünes Licht gibt, dann kann ich hier bald eine recht simple
Testanwendung Online zum Downloaden für euch anbieten.

Die Erlaubnis, die Testanwendung an einzelne, engagierte Fragenbeantworter
per Email zu verschicken, habe ich schon.

 

Hallöchen,

das verschicken einer Testanwendung ist vielleicht gar nicht nötig.

Statdessen gebe ich hier nochmal einen möglichst vollständigen Auszug der
Codeteile des Frontends wieder, die zur engeren Einkreisung des Fehlers nötig
sind:

Code:

Da hier nirgendwo das Rad neu erfunden wurde, kann das durchaus jeder
sehen.

Ausgangspunkt ist die Prozedur TabelleImportieren und das Problem tritt in
der Prozedur TabellenVerknuepfungErzeugen auf. Wo es auftritt, seht ihr hier:
Code:

Die Fehlermeldung lautet

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.

O.K. eigentlich eine klare Sache, irgend ein Parameter muß wohl falsch
übergeben worden sein, sollte man annehmen.
Genau diese Annahme ist falsch!

Access beschwert sich hier darüber, daß angeblich die vom Backend ins
Frontend zu verküpfende Tabelle nicht vorhanden ist. Wenn ich nach der
Fehlermeldung im Debugmodus weiter mache, dann befindet sich die gelbe
Markierung in der mit 'hier und nur hier tritt jetzt der Fehler auf
gekennzeichneten Zeile der Prozedur TabellenVerknuepfungErzeugen.
Wenn ich von da aus mit F5 oder F8 weitermache läuft der Code ohne
Fehlermeldung durch und macht genau das, was von mir beabsichtigt wurde,
nämlich die importierte Tabelle aus dem Backend ins Frontend zu verknüpfen.

Die angeblich nicht vorhandene Tabelle ist bisher in jedem Fall im Backend
vorhanden gewesen, d.h. der Import hat funktioniert.

Der Fehler tritt nicht immer auf, aber bei etwa 50% der Importversuche,
unabhängig davon welche Datei (oder Tabelle daraus) ich importiere.

Das Bekloppteste ist: Wenn ich das oben erwähnte Listenfeld, dessen
Datenherkunft im Backend liegt und rein gar nichts mit der dort erzeugten
Import Tabelle zu tun hat (auch keine Verknüpfung) weglasse oder dessen
Datenherkunft einfach leer lasse, dann tritt Laufzeitfehler 3011 nicht auf.
Der Code läuft ohne Beschwerde von Access durch und alles läuft wie
beabsichtigt.

Tja, also ich bin hier mit meinem Latein am Ende.
Aber Ihr doch nicht, oder?

 

Wie wäre es wenn Du dem Listenfeld die Datenherkunft über die Eigenschaft RowSource erst während der Laufzeit zu weist?

Oder vor Durchlauf der Prozedur die RowSource auf "" und erst nach Beedigung wieder die eigentliche Datenherkunft einstellst?

Erklärungen fehlen mir allerdings auch gerade, aber tippe mal das Josef P. noch was dazu einfallen wird. *wink.gif*

Gruß

Rainer

 

Hallo Rainer,

dein Bauerntrick funktioniert *grins

Einfach vor dem Import die Datenherkunft der bösen Liste auf
vbnullstring gesetzt, die Originaldatenherkunft in einem String
zwischengespeichert und nach dem Abschluß der ganzen Importgeschichte
wieder zurückgesetzt.

Das ist zwar nicht schön, weil die böse Liste während des Imports
zwischenzeitlich leer bleibt, aber so tut sich auf der Benutzeroberfläche
wenigstens etwas, während der Benutzer vom Hypnosecursor *wink.gif* beruhigt
wird.

Natürlich interessiert mich weiterhin eine Antwort, die das Problem bei
der Wurzel packt und löst, aber bei der täglichen Arbeit im MS-Office
Umfeld regiert ja sowieso der totale Pragmatismus, d.h. man darf sich
für keinen schmutzigen kleinen Trick zu schade sein.

Also, nochmals Danke für den Hinweis.

 

Nur so als Erklärungsidee:
M.W. werden die Datenquellen von List- und Kombifeldern als QueryDefs abgelegt (mit seltsamen Namen, die mit einer Tilde beginnen). Es könnte sein, dass diese Viecher Entwurfsänderungen an den Tabellen verhindern, solange sie geöffnet sind.

Ohne Datenquelle hat dein Listform keine solche QueryDef. Es sperrt dann auch nichts. -> Tadaa *Smilie

 

Diese Erklärung würde mir einleuchten, wenn die Import Tabelle, an die
mit der Prozedur ZusatzFelderEinfuegen drei Felder angehängt werden,
in der Datenherkunft der Liste auftreten würde.

Dies ist aber nicht der Fall! Die Datenherkunftstabelle der Liste wird
während des Imports nicht angetastet, lediglich unmittelbar vor dem
Import wird ein Datensatz mit Verwaltungsinformationen eingefügt.
Ein Veränderung am Entwurf dieser Tabelle findet im gesamten
Programm nicht statt!

Oder habe ich dich mißverstanden, Atrus2711?