Office: (Office 2003) Access Suchen und Ersetzen Datenbank tabellengestützt!

Das wird vermutlich nicht viel bringen. Man müsste mit "not like" o.ä. suchen, was zu einem Tablescan führt. Da kommt es imo auf das Update auch nicht mehr an.
Wäre es nur ein Suchkriterium, so wäre der Vergleich je Zeile sicherlich noch ganz gut brauchbar. Es müssen aber mehrere Kriterien geprüft werden. Ob sich dann eine extra Auswertung lohnt, bezweifle ich.

Folgendes könnte man eventuell probieren:
Code:

... Falls das jemand prüfen will: es wäre interessant, ob die Funktion ReplaceHtmlCodes(..) zweimal je DS ausgeführt wird. Wenn das das nur einmal je DS ausgeführt wird, dann könnte damit ein unnötiges Update ohne großen Zusatzaufwand verhindert werden.
/edit: ich probierte das gerade aus: es wird im Where und beim Update die Funktion ausgeführt. Jetzt müsste man dann noch klären, was schneller ist: mehrere unnötige Updates oder die doppelte Funktionsausführung bei den Treffern. (Wenn einige 100k DS ausgewertet werden müssen und darin viele Werte vorkommen, die keine Ersetzungen erfordern, könnte eine optimierte Funktion zur Prüfung eine Beschleunigung bringen.)

 

\@Josef P.: Also ich hab das jetzt mal spaßeshalber mit 1.000.000 DS getestet. Mit dem Ergebnis, dass die DS ohne WHERE-Bedingung deutlich schneller aktualisiert wurden, als mit der Bedingung feld > "" im UPDATE-Statement! Was mir auch intuitiv einleuchtet. Und Nu?

 

Warum? Oder hattest du keine leeren Felder in der Tabelle? (vermutlich auch keinen Index auf das Feld ... was aber durchaus der Realität entsprechen wird, falls das ein Datenfeld ist, nachdem nicht laufend gefiltert wird.)

/edit:
Wenn kaum leere Felder in der Tabelle sind, so kann das Weglasen von "where feld > ''" durchaus schneller sein. Dann darf man aber nicht vergessen, dass man NULL in der Funktion ReplaceHtmlCodes berücksichtigt. ... das könnte dann allerdings wieder dazu führen, dass die Variante mit >'' doch wieder schneller ist.
Imo gibt es keine "allgemein richtige" Variante, da das viel zu sehr von den vorhandenen Daten abhängt - und bei einmaligen Aktualisierungen für die Korrektur von Daten wird da auch ziemlich egal sein. *wink.gif*

 

... ok, ich hatte Leereingaben nicht berücksichtigt, dann ist die WHERE-Version deutlich schneller! Die indizierten Versionen (feld besitzt eine mehrdeutigen Schlüssel) sind aber für beide Fälle erheblich langsamer, als die nicht indizierten. D. h. doch dann wohl, dass das Aktualisieren von indizierten Spalten wesentlich langsamer ist, als das Suchen in nicht indizierten Spalten?

 

Meist wird aber viel mehr gesucht als aktualisiert, oder? *wink.gif*

Deine Feststellung zeigt aber sehr gut, dass ein Index auch bremsen kann. Daher sollten nur jene Indizes in die Tabelle, die auch (ausreichend) genutzt werden.

Außerdem: unbedingt immer die Index-Übersicht im Tabellenentwurf ansehen. Oftmals werden vor allem bei den PK-Feldern doppelte Indizes angelegt, weil diese doofe AutoIndex-Option aktiviert ist, die für Felder mit ID u. ä. automatisch einen Index setzt. Stellt man dann nachträglich auf so ein Feld den PK ein, hat man schon einen doppelten Index angelegt.

Eines sollte man auch nie vergessen: beim Verknüpfen von 2 Tabellen mit RI setzt Access automatisch einen Index, welcher aber im Index-Fenster nicht angezeigt wird.

 

Hier nun die Funktion, die an einigen Stellen noch überarbeitet wurde (am besten kopieren, ich weiß nicht, ob ich alles markiert habe):
Code:

Anwendung findet die Funktion dann so:
Code:

Hallo Arne,

ich bin leider jetzt erst zum Testen gekommen - funktioniert super vielen vielen Dank für die Unterstützung!

Viele Grüße

Webhungo

 

Natürlich auch einen herzlichen Dank an Josef und alle Anderen!

Viele Grüße

Webhungo

 

Ist es möglich, das von einem Feld auf eine ganze Tabelle auszuweiten?



Gruß
Benjamin

 

Letztendlich wird es darauf hinauslaufen, dass man jedes Feld mit der Funktion behandelt:

Code:

@Webhugo (falls du überhaupt noch mitliest): Bitte in Zukunft nicht mehr komplette Zitate verwenden - das ist meist überflüssig. Danke.

 

Das Problem was ich habe, ist dass ich Tabellen importiere, welche immer unterschiedlich viele Felder haben.

Das heisst, dass manchmal Feld 1 bis Feld 300 und manchmal Feld 1 bis Feld 250 vorhanden ist.


Daher wäre eine Universallösung, welches automatisch alle Felder durchsucht und ersetzt Gold wert für mich *rolleyes.gif*

 

Sind wirklich alle Felder zu behandeln? Dann könnte man sich eine Funktion basteln, die die Feldauflistung durchläuft und somit den SQL-String dynamisch zusammensetzen kann. Den String dann nur noch mit CurrentDb.Execute ausführen, fertig.
Falls es Ausnahmefelder (aufgrund des Datentyps o.ä.) gibt, müsste man das beim Durchlauf der Feldauflistung berücksichtigen.


Reicht das als Ansatz?

 

Bin mir nicht sicher ob miene Kenntnisse über Visual Basic dafür ausreichen. *frown.gif*

 

Anbei eine einfache Funktion, die Ausnahmen (Feldtypen oder bestimmte Namen) nicht berücksichtigt:
Code:

Die Funktion brauchst du zusätzlich zu dem Code in Beitrag #11. Eine Abfrage muss nicht angelegt werden - diese wird durch Aufruf von ?TabelleSaeubern("DeinTabellenname") ausgeführt.

 

Wow danke!

Jetzt machst du dir schon die Mühe und ich schaff es nichtmal die Funktion richtig auszuführen *frown.gif*


Wie meinst du das mit ?TabelleSaeubern("DeinTabellenname") ausführen ohne Abfrage?

 

So kannst du die Funktion im Direktbereich ausführen. S. dazu Das Debug-Fenster (Klick mich).