Office: (Office 2016) Nach PDF oder Doc suche einschräknen

Oops...
na hier noch mein Dich überlappend habender Beitrag.
Bin natürlich gespannt, was Du da bietest.
Ist ja fast wie ein 6er im Lotto wahrscheinlich.

mein alter Text:
danke Knobbi38,
ich hatte genau dasselbe Gefühl bezgl. des dauernden Neuerstellen eines ShellObjects.
Ich fürchte nur, dass ich da einige Probleme beim Umsetzen haben werde.
Ich setz mich aber nun erst einmal auf den Hosenboden und versuche, Deine Optimierungsvorschläge umzusetzen.
Das Forum und Du, Ihr werdet also erst einmal Ruhe vor mir haben.

Du wirst es wahrscheinlich nur noch bei sehr komplexen Programmierungen
als einen Erfolg werten, wenn erst einmal funktioniert, was man da so
"gebastelt" hatte. Danach kommt dann die Überlegung der Optimierung des Codes. So mache ich es.

Ich bin momentan stolz, die Spiellänge eines Audiofiles schon mal auch einlesen zu können und in der Tabelle zu speichern.

Nun taste ich mich weiter vor.

schönen Abend noch und nochmal Danke für die Geduld und Dein Lottogeschenk.

 

Servus knobbi38,
ist doch immer wieder lehrreich, wie ein Profi an so ein Thema rangeht.
Zusätzlich auch ein Danke für den Tipp:

 

Vielen Dank für Eure Mühe besonders Dir knobbi38 genauso hab ich es mir vorgestellt. Du bist genial. Nun werde da ich ja auch was lernen will mir den Code geanau anschauen, hoffe das ich wenigstens die hälfte davon verstehe. Da ich seit einigen Jahren durch ein großes Privates Programm mich gar nicht mehr um Access gekümmert habe und auch schon von meinen wenigen Wissen einiges vergessen habe Werde anscheinend älter > 60. Finde ich es toll das Ihr euch die Mühe gemacht habt mir zu helfen, was nicht sebsverständlich ist. also *Smilie *Smilie Vielen Dank für die Mühe und Zeit.

Karl-Heinz

 

Servus knobbi38,
ich hab mal die beiden Versionen geschwindigkeitsmässig anhand des
Auslesens eines Musikordners mit 26616 Songs, auf viele Ordner und Subordner verteilt, verglichen.
Die Einbindung der Objshell Objekte in Deine Funktion bringt überraschend wenig bis gar keinen Geschwindigkeitsvorteil.
Die meiste Zeit braucht das Importieren (ca. 10 min. +/- ca. 3 Sek.) der Zusatzinfos (Metatags) in beiden Versionen.
Auf jeden Fall überlege ich, ob ich meine seit vielen Jahren wunderbar funktionierende Musikplayerversion einem Update bezüglich Deiner schnelleren Geschwindigkeit des Importierens von Songs unterziehen sollte.
Meine Importe aus diesem oben benannten Musikordner bekommen allerdings dabei auch viele Zusatzinfos (bis zu 30 Metatags pro Song,
extern generierte Genre-Zuordnungen, extern generierte Musikart-Zuordnung, extern generierte Programmart-Zuordnung, etc.
So weiss ich noch nicht, ob das alles Deinen Geschwindigkeitsvorteil auffressen könnte.
Aber das teste ich jetzt mal....*biggrin.gif*

 

Anmerkungen:
Wenn man auf Geschwindigkeit zielt, sollte man berücksichtigen/prüfen:

1)
Code:

Statt den Index des Arrays immer um 1 zu erhöhen würde man besser einen praktikablen Startwert für den Index setzen, und dann, wenn die Einträge den Index erreicht haben, diesen Index jeweils verdoppeln.
Am Ende setzt man dann den Index auf den Wert der Anzahl der realen Beiträge.

2)
Code:

Das Gleiche, was oben zum Shell-Objekt gesagt wurde, gilt natürlich auch für das FSO-Objekt. Da sich die Funktion selber rekursiv aufruft, wird hier das Objekt jedes mal neu instanziert.
Hier sollte man ebenfalls mit einer Instanz arbeiten und in der Funktion "nur" auf diese referenzieren.

3) Statt an FileSystemObject könnte man beim Dateierfassen an Win-API's denken. Nepomuk hatte mal einen entsprechenden Code als Ersatz für das abgeschaffte FileSearch veröffentlicht.

 

________________________________________
@Ohrkester:
Die Funktionen habe ich jetzt nicht explizit auf Geschwindigkeit getrimmt, sondern die praktische Umsetzung stand hier mehr im Vordergrund.

Evar46 hat das Beispiel nur für seine Zwecke entsprechend modifiziert, so wie man eben Code wiederverwenden sollte.

Das Abrufen von Metadaten mit der Shell ist bestimmt nicht die optimalste Variante und ist sicherlich zeitintensive. Wenn du mehrere Metadaten für eine Datei abrufen möchtest, würde ich das in einem Rutsch machen und eventuell die Funktion GetDetailFileInfo() entsprechend erweitern. Dann müssen die Objekte nicht für jedes Attribut neu erzeugt werden. Ist vielleicht ein Kompromiss, mit dem man leben kann, denn normalerweise werden solche Importe ja nur für neue Dateien gemacht.
Wenn es um nackte Geschwindigkeit geht, kann man auch per FileAPI direkt auf die Metadaten zugreifen, wenn man den weiß wo sie für die einzelnen Dateitypen zu finden sind.

@Eberhard
natürlich hast du mit dem FSO-Recht, wenn du sagst, daß das bei jeder Rekursion neu erzeugt werden muß. Hier habe ich aber nur auf eine vorhandene Funktion zurückgegriffen, die ich ein wenig modifiziert habe und diesen Algorithmus wollte ich nicht noch großartig verändern. In dem Fall habe ich eine Abwägung gemacht und da ein FSO-Objekt nur für jeden neuen Subordner neu angelegt wird, alles so belassen. Das kann, glaube ich, in einer realen Umgebung vernachlässigt werden - wird eh gecached.
Auf eine besondere Verwaltung des Objekt-Arrays habe ich ebenso bewußt verzichtet, weil ich das Beispiel nicht noch komplizierter machen wollte. Vielleicht etwas für eine OOP-Lösung.

Das mit dem Shell-Objekt und den Metadaten sollte in erster Linie auch als Beispiel dafür dienen, wie man vorhandene Funktionen/Module einigermaßen geschickt wieder verwendet. Eine Instanziierung des Shell-Objekts pro Dateiname fand ich aber dann doch ein wenig zu viel und ich wollte einen Weg aufzeigen, wie so etwas umgangen werden kann.

Das es für das Problem auch andere, möglicherweise performantere Lösungen gibt, ist mir schon bewußt, aber wenn es nur um wenigen Minuten geht ...

Gruß Ulrich

 

danke Knobbi38,
nun ergibt sich ein neues Problem mit Deiner Beispiel DB aus #30.
Erstellt man darin eine Abfrage über den Abfrageassistenten
auf die Tabelle 'tblDateien' und will in der Spalte 'Firmenname' etwas mit dem Like-Operator in den Kriterien filtern, dann wird immer aus dem eingegebenen
Code:

automatisch ein
Code:

statt eines
Code:

Das ergibt natürlich, dass nix gefunden wird, da es ja heissen müsste
Code:

Woran kann das denn liegen?
Ich benutze Access 2016 und hab natürlich die DB komprimiert und repariert.

 

Hallo Ohrkester,

dann wird die Datenbank im SQL-ANSI 92 Mode verwendet, anstatt im SQL-ANSI-89 Mode (siehe Access-Optionen->Objektdesigner).

Access konvertiert dabei automatisch alle Like-Anweisungen in ALike-Anweisungen und wird dann zusammen mit den entsprechenden Platzhaltern von ANSI-92, also '%' anstatt '*' usw. verwendet.
Die Funktion ALike stellt dabei Rückwärtskompatiblitat zu Ansi-89 her, d.h. ALike mit "%" sollte unter ANSI-89 genauso funktionieren wie Like mit "*".

Ulrich

 

auch wieder mal ein grosses Danke von mir an Dich.
Man lernt halt nie aus.