Office: (Office 2016) Dateien und Verzeichnisse

Hallo,

mit folgendem Code lese ich aus einem Verzeichnis alle Unterverzeichnisse inkl. der Dateien aus.

Code:

Mit Debug.print natürlich kein Problem, aber wie bekomme ich die Daten jetzt in meine Tabelle?

Mir fallen hier nur 2 Möglichkeiten ein:
Möglichkeit 1: Ich schreibe die Date in ein Array und lese dies dann in einem weiteren Schritt über ein Recordset ein. Hier Frage ich mich, wie ich das Array dann deklarieren muss, damit es nicht verloren geht.
Möglichkeit 2: Anstelle der debug.print ANweisungen schreibe ich die Daten direkt in ein Recordset. Da die Funktion aber rekursiv ist, würde dann aber das RS immer neu erstellt, was sicher zeitintensiv ist, oder?

Gibt es andere Lösungsvorschläge/möglichkeiten oder welche der o.g. wäre die sinvollere oder...oder... :-)

:)

 

Hallo
wie wäre es mit einer Anfügeabfrage?

 

Stilistisch sauber würde man das Recordset als Argument an die Funktion übergeben. Damit würden innerhalb der Funktion nur Datensätze angefügt.

Das FSO-Objekt wird übrigens auch jeweils neu erzeugt ...

 

\@Eberhard:

ist richtig, aber nur für jedes Verzeichnis und weil der Zugriff auf die Bibliothek (DLL) vom OS gecached wird, kann das praktisch vernachlässigt werden.

Das Recordset mit durchzuschleifen, würde ich jetzt hingegen nicht machen. Dann doch lieber ein Array, welches dann nach dem Aufruf in einem Rutsch verarbeitet wird, wenn es geht vielleicht sogar mit UpdateBatch oder innerhalb einer Transaktion.

Gruß Ulrich

 

Erkennen, was man tut, und vernachlässigen sind unterschiedliche Dinge.

Den bereits begonnenen Erkenntnisprozess wollte ich nur etwas aufbohren.

Das Vernachlässigen hat auch damit zu tun, dass das Verhalten in Summe nicht laufzeitkritisch wird. Solch ein Zustand kann sich aber ändern (viele Schleifenläufe, Abfragen über größere Tabellen).
Es soll ja vorkommen, dass man bereits ein zweifaches CurrentDb durch eine einmalige DB-Referenz ersetzt.

Mit der angedeuteten Stilistik wäre man unempfindlich und überraschungsfrei bei Datenmengenvergrößerungen.

Sowie: Wenn ich direkt in eine DB-Tabelle schreiben kann, spare ich mir eine Umschichtung über ein Array. Im Unterschied zu Excel kann man nicht den Arrayinhalt im Stück in die Tabelle schieben.
Bei einer vorab unbekannten Inhaltsmenge kann man sich zudem mit der Redimensionierung des Arrays zusätzliche Probleme, auch performancetechnisch, einhandeln.

 

Wäre dann nicht die Anfügeabfrage die "beste" Lösung?

 

Abfragen sind meist eine gute Lösung. Da braucht man mich nicht überzeugen.

Das "Beste" ist aber immer auch abhängig von Aufgabenumfeld und durchaus auch von eigenen Vorlieben: Bei Dingen, die ich verstehe und beherrsche, tue ich mich leichter und fühle ich mich wohler.

Hier würde per Anfügeabfrage immer nur ein Datensatz erzeugt, ausgehend von einem Array dann auch. Das heißt dann pro Einfügung ein Tabellenzugriff. Zusätzlich haben viele mit der Einfügung von Werten von außen Syntax- und Datentypenprobleme (das Forum ist voll davon).
Das sind jetzt keine unlösbaren Herausforderungen. Im Gegenteil.
Das Recordset ist hier aber eine gesunde Alternative und performancetechnisch etwa gleichwertig.

 

Das kann ich gerade bestätigen. Habe beide Varianten getestet und merke keinen Unterschied. Allerdings hat mich das SQL Statement (mal wieder) fast an den Abgrund geführt :-)

Danke für euren Input.

 

Der "Umweg", so wie du ihn beschreibst, hat bei der Verarbeitung durchaus Vorteile und es geht hier um das Durchsuchen eines Filesystems, also um IO-Zugriffe. Deine Bedenken hinsichtlich Performance und Redimensionierung des Arrays sind in dem Fall zu vernachlässigen, das sind Referenzen auf Objekte die sowieso schon instanziert sind, und ich denke, ich habe das erkannt, was ich tue und auch warum ich das genau so tue.
Der Vorteil mit dem Array ist, daß man hierbei auf eine gut getestete generische Funktion zurückgreifen kann und anschließend individuell das Array verarbeitet wird, was mit der Übergabe eines Recordsets so nicht möglich wäre.

Gruß Ulrich

 

An der Stelle erkenne ich nur die vollständige Erfassung.

Was eine Person selber genau tut und eine pauschale Empfehlung sind nicht das gleiche.

Keiner hat gesagt, es würde nicht funktionieren.

Wie gesagt: Aufgabenumfeld.
Der Erstbeitrag ließ eindeutig darauf schließen, das Tabelleneinträge gewünscht sind. Will man etwas anderes, dann kann man auch etwas anderes tun.

Der Fall selber würde nicht beschrieben. Bei einem umfangreichen Dateisystem mit vielen Ordnern und Dateien und schönen langen Pfaden hat man eine gute Chance, dass sich Laufzeitauswirkungen bemerkbar machen.

Was nicht jeder bemerkt: Ich wies nur auf mögliche Fälle und Probleme hin. Ob die wegen einer konkreten Situation und/oder einer individuell vorgenommenen Gestaltung eintreten oder wahrgenommen werden, ist ein anderes Thema.

 

\@Eberhard:

Doch: durchsuchen eines Filesystems nach Ordnern und Dateinamen

Diese Aussage trifft genauso wenig zu!

https://www.ms-office-forum.net/foru...0&postcount=27
In diesem Thread hast du schon mal ähnliche Vermutungen angestellt. Kannst das ja mal anhand der Demo-Datenbank testen, wieviel das wirklich ausmacht, dann aber den Part mit der Prüfung auf "bereits vorhanden" auskommentieren.

Gruß Ulrich

 

Alle heißt alle. Übrigens auch beim Durchsuchen, weil man alle durchläuft und ggf. nur gefiltert übernimmt.

Laufzeitrelevanz:
Code:

Daneben: Ein Array muss komplett im Arbeitsspeicher gehalten werden. Wird es groß genug dimensioniert, bekommt man einen Laufzeitfehler bis Absturz.

Eine Tabelle / ein Recordset kann dagegen teilweise in die Auslagerungsdatei geswitcht werden, so etwas macht die DB-Maschine laufend. Es dauert dann etwas länger, aber es geht weiter.

 

Genau, wenn es mehrere Millionen Einträge werden, hast du vorher wohl einen Stack overflow wegen der Rekursion.

Bei dieser Vielfalt an Weisheiten wird einem ganz anders. *grins *grins
Ich wäre für ADO.Command mit Prepare und für den Verzicht der Rekursion,
da hätten wir dann den Gipfel der Programmierkunst erreicht und erst mit dem Limit von einer Access Datei ein Problem. *grins

 

\@Eberhard:
Du drehst dir die Welt gerne, wie du sie brauchst, oder? Was soll so ein Test aussagen? Das die dynamische Vergrößerung eines Arrays länger dauert, als eine einmalige Allokation? Das ist doch nichts Neues und gehört zum kleinen Einmaleins. Hier geht es aber nicht darum, sondern falls du es noch nicht gemerkt hast, um IO-Zugriffe zum Lesen von Filesystem Einträgen. Die dafür benötigte Zeitspanne ist i.d.R. um Größenordnungen länger, als Zugriffe auf den Speicher, mal abgesehen davon, daß der Kernel dabei auch noch Kontext Wechsel macht. Dein Beispiel würde mehr Aussagekraft haben, wenn Referenzen auf Objekte und IO-Zugriffe verwendet worden wären.
In diesem speziellen Fall kann deshalb m.E. nach die zusätzliche Zeit für die dynamische Allokation vernachlässigt werden. Außerdem werden bei dem Verfahren immer nur so viele Ressourcen verbraucht, wie gerade unbedingt benötigt werden. Deshalb ziehe ich diese Strategie sogar vor. Sicherlich könnte man die Allokation auch noch etwas optimieren, wenn der Aufwand das rechtfertigten würde.
Dein Einwand, daß ein Array im Speicher gehalten werden muß, ist eher nebensächlich. Führt die Größe des Arrays zum Speicherüberlauf, sollte man besser eine andere Strategie als Lösungsansatz verwenden. Dieses Verfahren wäre dann eben nicht zielführend. Alternativ könnte dann z.B. die von markusxy vorgeschlagene Variante verwenden werden.

Und die Haarspalterei mit

ist eher irreführend - du weiß genau, was der OP und ich dem Sinn nach gemeint haben. Weshalb sollte man alle Dateinamen eines Filesystems ungefiltert in eine Access-Tabelle aufnehmen wollen? Wahrscheinlich hat dann Access eher ein Limit erreicht, bevor ein dynamisches Array einen Speicherüberlauf erzeugt. Das dürfte in der Praxis wohl kaum vorkommen.
Wenn es wirklich um Performance geht, dann nimmt man eh API Aufrufe und wenn das noch nicht reicht, können noch bestimmte Eigenschaften der Devicetreiber ausgenutzt werden, aber das ist eine ganz andere Baustelle.

Gruß Ulrich

 

Das war doch nicht ernst gemeint.
Aber wenn man bei solchen Nebensächlichkeiten mit Systemgrenzen argumentiert, dann bleibt bei mir nur Sarkasmus übrig.

Außerdem dynamisches erweitern eines Arrays für jeden Eintrag finde ich auch ziemlich unterirdisch. Da schreibt man sich einmal eine Klasse die den Vorgang sinnvoll managend und erfindet das Rad nicht jedes mal neu. *wink.gif*