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

Hallo liebe Fragenbeantworter in diesem Forum,

zur Zeit werde ich von einem Problem mit dem unten stehenden Code aufgehalten, das ich selbst nicht lösen kann.
Es geht darum, eine Excel Tabelle in ein Access Backend zu importieren und anschließend an die importierte
Tabelle eine Spalte vom Typ Boolean anzufügen, die in der Datenblattansicht als Kontrollkästchen erscheint.
Die allermeisten Details zur Lösung dieser Aufgabe sind mir bekannt, bis auf:

Nachdem das Accessobjekt des Backends nach dem Import der Excel Tabelle wieder geschlossen wurde scheint
ein Zugriff auf das TableDef Objekt dieser Tabelle vom Frontend aus über

DBEngine.Workspaces(0).OpenDatabase(PfadBackend).TabelDefs

nicht sicher möglich zu sein, denn meistens findet die Suchfunktion GetTblDef (Code unten) das TableDef Objekt der importierten
Tabelle nicht und liefert nothing als Ergebnis. Schaue ich dann explizit im Backend nach, so ist die gesuchte
Tabelle aber darin vorhanden, d.h. der Import hat funktioniert. Ein Aufruf von TabelDefs.Refresh vor der Suche nach
dem TableDef Objekt der importierten Tabelle hat bisher nicht geholfen.

Wenn ich die Suchfunktion GetTblDef Schritt für Schritt im Debugger durchlaufe, dann wird das gesuchte TableDef Objekt
allerdings mit größerer Wahrscheinlichkeit gefunden.

Kennt jemand von euch dieses Phänomen mit Access XP auf Windows Vista und weiß einen Rat?

Code:

:)

 

mal grundsätzlich die Frage:

Ist denn der Aufbau der Excel-tabelle immer anders oder ändert der sich?

Gruß

Frank

 

Der Aufbau der Excel Tabelle soll egal sein, bis auf die erste Zeile, denn die soll die Spaltennamen enthalten.
Beim Import aus Access tritt das oben geschilderte Problem mit der TableDef ebenfalls auf!

 

Die Frage war glaube ich eher nicht auf die Zeilen sondern auf die Spalten der Exceltabelle bezogen, die ja nachher auch die Spalten/Felder in der Tabelle werden/sind. Und wir versuchen zu verstehen, worin der Zweck dieser Aktion liegt. Ich mache Excelimports bspw. nur indem ich die Daten importiere, aber die Exceltabelle der Datenbanktabelle anpasse und nicht umgekehrt.

Wo wird die Variable NameTblInBackend gefüllt?
Hast Du geprüft ob sowohl bei db als auch bei NameTblInBackend Werte enthalten sind? Nach dem Fehler kannst du mit dem Cursor der Maus auf die beiden Variablen gehen und schauen ob da was drin steht.

Das Problem kann auch eine Zeile weiter oben sein. Wo wird die Variable PfadBackend gefüllt? Bzw. ist da ein Wert drin?

 

Was heisst das konkret? Kommen da immer verschiedene Spalten oder ist das eine definierte Exceltabelle mit immer gleichem Aufbau nur eben dem fehlenden Feld?

Gruß

Frank

 

Danke für eure Aufmerksamkeit!

Ich weiß heute noch gar nicht wie die Excel Tabelle konkret aussehen wird!
Mir scheint allerdings, daß der konkrete Aufbau der Excel Tabelle nicht so wichtig ist.
Der Code soll jedenfalls funktionieren ohne zu spezielle Voraussetzungen an die Excel Tabelle zu stellen.

Das dao.database Objekt db in GetTblDef ist beim Aufruf definiert, denn im Debugger sehe ich, wie zunächst
die TableDefs der Systemtabellen abgefragt werden.

Das Anfügen der Spalte zum Abhaken sollte ebenfalls irrelevant sein, weil
das Problem ja davor auftritt.

Ich habe im zitierten Quellcode nicht jede Kleinigkeit angegeben und wollte
nur das wesentliche durch sprechende Namen unterstreichen: Gehen wir
mal davon aus, das der Aufruf von GetTblDef mit wohldefinierten Parametern
erfolgt, d.h. in strTblName steht der Name der gesuchten Tabelle und nicht
"" und an db wird ebenfalls ein korrekter Verweis auf die Backend Datenbank
übergeben.

Der Witz ist: Der Code funktioniert durchaus, aber nicht immer.
Im Debugmodus funktioniert der Code wesentlich häufiger.

 

Wie soll diese dann nach dem Import sinnvoll verwendet werden? Feldnamen und Datentypen könnte man noch per Code ermitteln, eine inhaltliche Anbindung an das bestehende Datenmodell erscheint mir aber problematisch.

Ein üblicher und einfacher Weg wäre es, die Exceltabelle zu verlinken (TransferSpreadsheet acLink) und die benötigten Daten per Abfragen in die vorhandene BE-Tabelle (mit vorhandenen Beziehungen, allen benötigten Feldern, Indizes usw.) zu übernehmen. Die Abfragen können dann auch wegen der Einfachheit auf die verlinkte Tabelle im FE angewendet werden.

(Wegen o.g. Hinweise habe ich mich noch nicht mit Deinem konkreten Code auseinandergesetzt.)

 

Die Function GetTblDef() hat im Falle, dass das Exit For erreicht wird, keinen Rückgabewert.
Es müsste also entweder dafür gesorgt werden, dass da immer ein Wert zurückgegeben wird oder beim Aufruf (in der von Dir auch als problematisch erkannten Zeile) auf Nothing geprüft werden, bevor die Zuweisung an eine Variable erfolgt.

 

Die Idee zur sinnvollen Verwendung läßt sich einfach skizzieren:

Die importierten Daten können ja in einem Unterformularsteuerelement in
der Datenblattansicht angezeigt werden, ohne das ich vorher wissen muß wie
die Felder der Tabelle heißen und was da drin steht. Dazu setzt man einfach die
SourceObject Eigenschaft des Unterformularsteuerelementes auf Tables.Importtabelle
und so kann ich erst zur Laufzeit die angezeigte Tabelle festlegen.

Die weitere Verarbeitung der noch gar nicht bekannten Daten ist natürlich
nicht möglich, aber ich kann immer Spalten an die importierte Tabelle anhängen und dem kundigen
Nutzer (Dateninterpret) anbieten, die Zeilen, die zur weiteren Verarbeitung gewünscht sind, selbständig
zu markieren. Deswegen werden der importierten Tabelle Kontrollkästchen hinzugefügt!

Wie man ein solches Kontrollkästchen anfügt steht oben im Code. Falls ihr das
gebrauchen könnt: Kopiert es euch!

 

Ich könnte mir schon gut vorstellen, dass wenn deine Anforderung steht, dass die zu importierenden Tabellen in der Regeln einem festen Format kommen.

Dann wäre es nicht schlecht die Tabelle wie sie kommt in eine "Importtabelle" zu importieren. Danach kannst du diese in deine "produktive" Tabelle im Backend überführen und diese hat dann eben nochweitere benötigte Felder welche du in der Anfügeabfrage eben sinnvol belegen kannst. Ausserdem kannst du so sicherstellen, dass keine Dupletten erzeugt werden oder neue Datensätze besonders behandelt werden ...


Du siehst vielleicht, dass unser Hinterfragen nach Details un dem fahclichen Hintergund nicht unbegründet ist?

Gruß

Frank

 

Die Frage ist ja:

Warum erreicht der Code das Ende der For Next Schleife obwohl
die Tabelle, deren Name mit dem Parameter strTblName übergeben wird in db
vorhanden ist. Wenn ich im Backend nachgucke, indem ich die Access Datei
öffne, dann ist die gesuchte Tabelle darin enthalten, wird aber von fraglichem
Code nicht gefunden.

Wenn ich im Debugmodus den Parameter strTblName überprüfe, dann steht da
immer der gewünschte Name drin und db wüsste ich auch nicht anders zu
initialisieren als oben angegeben.

 

Die Tabelle kann recht groß werden, z.B. mehrere hundert MB, da erspare ich
mir am liebsten jede zusätzliche Kopie der Daten. Das gleiche Code-Gerüst soll
auch für den Import von Access Tabellen genutzt werden, und die können noch größer ausfallen.

 

Schau Dir doch noch einmal die Logik Deiner Schleife an:

Was genau passiert, wenn eine Tabelle, die in For Each gefunden wird, mit dem gesuchten Namen übereinstimmt?
Die Schleife wird verlassen ohne dass der Rückgabewert gesetzt wird. Erst danach wird er gesetzt.

Und andersherum, wenn keine der Tabellen in der Aufzählung mit dem Namen übereinstimmt, wird das (zufällig) letzte Objekt zurückgegeben ... da kann doch etwas nicht stimmen ... vielleicht besser so:
Code:

@All: mal nebenbei, ich finde es ja geradezu entzückend, wie sich in das Geschehen auf dem Nebenkriegsschauplatz verloren wird ... die Logik des Codes hat sich wohl keiner so genau betrachtet, oder? Ich gebe zu, ich habe es auch erst nicht gesehen.

 

Hilft so etwas?
Code:

Wenn es um den gezeigten Code geht - ohne Schleife geht es auch:
Code:

 

es gibt für alles Lösungsansätze.
- die zu importierenden Tabellen nicht als Importtabellen reinziehen sondern verlinken
- die zu imporienden Tabellen (egal ob aus Excel oder Access) in eine temporären Backend-MDB importieren, dieser kommt quasi leer und kann danach wieder gelöscht werden. So bläht sich dein tatsächlicher Backend nicht mehr auf als nötig.

So hatte ich vor ein paar Jahren MIt Datenmengen im Bereich von mehreren GB gearbeitet. => DB fachlich in mehrere Backends aufgeteilt und diese nicht mehr aufblähen als nötig.

Gruß

Frank