Office: (Office 2016) Abfrage im Hintergrund

Hallo zusammen,

gibt es eigentlich eine Möglichkeit eine Abfrage im "Hintergrund" laufen zu lassen, sodass man während diese läuft anderweitig weiterarbeiten kann?

Hintergrund meiner Frage ist, dass ich eine etwas aufwändige Abfrage habe, die 10 min braucht und in dieser Zeit kann man nichts anderes mit der Datenbank tun.

Gruß
Klaus

:)

 

Bei Aktionsabfragen könnte man vermutlich ein VBScript starten, welches die Access-/Jet-Engine entsprechend automatisert.

 

Hallo Nouba,

Du sprichst in Rätseln.

???

Gruß
Klaus

 

Ich stimme grundsätzlich zu, würde aber nicht die Ace-/Jet-Engine automatisieren (was ich als Zugriff über DAO deute), sondern stattdessen die Abfrage über ADO ausführen. Letzteres ist im VBScript-Kontext der Quasi-Standard und daher wesentlich ausführlicher dokumentiert. Z.B. in diesem sehr ausführlichen (aber Englischen) Technet-Artikel zum Access-Datenbankzugriff mit VBScript.

 

Woraus wäre die Aufwändigkeit abzuleiten?

Primär würde man versuchen, die Laufzeit der Abfrage zu verkürzen statt als gegeben zu nehmen. Manchmal hilft ja schon ein Wimpernschlag: Performance total mies

 

Hallo Eberhard,

das mit der Performance verbessern ist mir bisher nicht gelungen.

Ich mache folgendes:

• aus einer Tabelle mit >10.000 DS werden alle aus diesem Jahr ausgewählt (~2000-2500)
• jeder DS hat einen Mitarbeiter [Name und ID], eine Tätigkeit und eine Zeitspanne [Start] und [Ende]
• in einer Prozedur werden aus jedem DS so viele DS kreiert (als Recordset) wie die Dauer ist. Für jeden Tag ein DS mit MA_ID, Tätigkeit und dem Datum; von [Start] bis [Ende].
• in der selben Prozedur wird dann dieses Recordset durchforstet und für jeden MA ein DS angelegt mit einem Textfeld, welches jedes Datum und Tätigkeit enthält.
• ...hier entsteht das Problem: es werden pro Mitarbeiter mehrere identische DS gebildet (so viele wie die original Tabelle Einsätze pro MA hat)
• Um nur noch einen DS pro Mitarbeiter zu erhalten, habe ich eine "INSERT INTO... SELECT DISINCTROW..." Abfrage, die für jeden MA nur einen DS erstellt. Mit SELECT DIDTINCT kann ich leider nicht arbeiten, weil das Textfeld zu groß ist und dabei abgeschnitten wird.

Ich bin für Tipps, wie ich das performanter gestalten kann sehr empfänglich. *wink.gif*

Gruß
KLaus

 

Mit einer Hilfstabelle geht das schneller und entspannter.

Hier würde ich an eine Abfrage mit Filter denken.

Ungewünschte Datensätze würde ich gar nicht erst erzeugen, dann muss man keine beseitigen. Weniger Menge macht weniger Arbeit.

Wird da mit Memofeldern jongliert? Berge sind schwerer zu versetzen als Steinchen.

=> Auf Beschreibungen kann man oft nur per Beschreibung antworten. Konkrete Vorschläge bedürfen der Kenntnis der konkreten Situation => Demo-DB.
Zudem sollte man sich vergewissern, mit welchem Backend man arbeitet.

 

Hallo Eberhard,

Im Anhang die Demo Datei.

Ich komme daher, dass ich das (geniale) Gantt Demo von Sebastian aus dem Code Archiv auf eine Plantafel umbauen will.

Um mehr als einen Einsatz in für einen Mitarbeiter anzeigen zu können, muss ich für jeden Mitarbeiter alle Einsätze in einen Datensatz (Zeile) bringen, damit ich das mit der bedingten Formatierung anzeigen kann.

Dazu muss ich alle Einsätze [Start] bis [Ende] in "Einsatz an Tag X" auflösen und dann alle DS in ein Memofeld einlesen.

Das macht die Prozedur lday(MA).

Jetzt erstellt diese Prozedur aber so viele DS pro Mitarbeiter, wie er Einsätze im Zeitraum hat. Hier ist mir noch nichts gutes eingefallen, wie ich das Erstellen der Duplikate vermeiden kann.

Um die DS wieder zu "vereinzeln" habe ich die Abfrage "qry_GanttCreat" mit SELECT DISTINCTROW eingebaut.
So wie ich das sehe, ist diese Abfrage auch der größte Zeitkiller.

Ich bin für jede gute Idee zur Performanceverbesserung dankbar!

Gruß
Klaus

 

Code:

=>
Code:

[MA-ID] ist eine Zahl und indiziert und somit sinnvoll für eine performantere Verwendung.

Code:

Hier sind einige schlimme Dinge versammelt:
- rot: Vergleich mit Text und keine Indexnutzung, wieso Verwendung von LIKE (Mustersuche). Durch Wandlung des Arguments und somit des Vergleiches auf MA-ID wird eine Besserung eintreten.
- violett: Felder sind nicht indiziert. Warum nicht?
Verstehend lesen: Grundlagen - SQL ist leicht (8) - Index

Code:

Wie soll die Baugruppe in der bedingten Formatierung ausgewertet werden?

Code:

Ein einmaliges Vorwärtslesen der Datensätze ist weniger aufwändig, als das Öffnen des Recordsets als Dynaset (Standard), wo auch Schreibaktionen bis hin zu Transaktionen verwaltet werden müssen.

Weiter ist die Textzusammensetzung per VBA wie verwendet sehr ungünstig: Die Stringvariable belegt einen Speicher entsprechend ihres Inhaltes. Wird jetzt ein Inhalt hinzugefügt, muss ein neuer daür passender Speicherplatz gesucht werden und dann erfolgt eine Umschichtung dahin. Bei sehr langen Zeichenketten und vielen Vorgängen kann das spürbar zeitrelevant werden.

So, fassen wir kurz zusammen: Schlechte Filterung im Recordset, ungünstige Textzusammensetzung, das Recordset selber ist auch Aufwand. Das wird dann pro Datensatz wiederholt, womit alle Sünden vervielfältigt und summiert werden. Diese Wiederholungen finden dann noch zu oft statt, das eingangs erwähnte DISTINCT senkt die Datensatzzahl von 2.186 auf 103 (knappe 5 Prozent).
Ein drastisch flacheres Recordset (der Eingangsabfrage) wird den RAM-Bedarf senken und deutlich Verschiebungen von Daten auf die Auslagerungsdatei (HD) reduzieren, die Verzwanzigfachung des Tempos (100 / 5 = 20) wird da noch angehoben.

Bezüglich Textzusammensetzung sollte man auf die ADODB-Methode Getstring umschwenken, die ist weitaus schneller. Nouba hat das in einer Funktion gekapselt:
Code:

 

Wenn man das dann alles umgesetzt hat, sollte man zusätzlich berücksichtigen, dass die bedingte Formatierung an sich auch nicht gerade eine Performancebestie ist. Wenn man also die 103 Mitarbeiter über das ganze Jahr darstellen will, sind das 103 * 365 = 37.595 Einzelprüfungen im Formular, die dann für sich auch ihre Zeit brauchen.

Vielleicht sollte man da etwas Professionelles verwenden und dort überschaubare Euros statt unendliche eigene Zeit investieren, siehe z.B. Flexibles DataGrid und ListView-Control

 

Hallo Eberhard,

VIELEN DANK!!

Die Hinweise und Codeoptimierungen sind super! Das hat schon mal einen Performancesprung von ~ 10min auf 15 sec gebracht.

Ein paar Fragen und Kommentare habe ich noch:

Das Textfeld MA zu nutzen anstelle MA-ID war ein Schlampigkeitsfehler. Ich habe es später auch gemerkt, war aber faul es umzubauen, weil ich auch nicht gedacht hätte, dass dies viel ausmacht. *redface.gif*

Ich muss gestehen, die geänderte Abfrage verstehe ich nicht vollständig. Was genau da passiert , auch mit dem X erschließt sich mir noch nicht, aber es funktioniert super (ich konnte auch noch zusätzlich das Feld MA einbauen, das brauche ich ja für die Darstellung) und ich werde mich da reinbeißen und versuchen es nachzuvollziehen.

Das Thema "Index" ist bei mir noch nicht ins Bewusstsein gesickert. Das passiert mir noch ständig, dass ich das vergesse. Gelobe Besserung!
Werde mir mal die ganze "SQL ist leicht" - Reihe reinziehen. Denke, da muss ich noch viel lernen.

Die Baugruppe wird auch per InStr ausgewertet, klappt super, ich kann zumindest drei Tätigkeiten (farblich) unterscheiden. Wenn man per VBA Code mehr als drei bedingte Formatierungen definieren könnte, würde ich hier noch mehr farbliche Unterscheidungen einbauen. ...aber "zu Fuß" ist mir das zu aufwändig.

Die Getstring Variante werde ich jetzt auch mal noch versuchen einzubauen.

Vielen Dank für den Tipp mit dem link zum "flexibles DataGrid ...". Das schaue ich mir mal an, sieht sehr interessant aus.

Klar, die bedingte Formatierung ist jetzt sicher keine professionelle Lösung, aber ich bin schon ganz begeistert, dass man die Aufgabe auf diese Weise überhaupt lösen kann. Und mein Anwendungsfall ist jetzt nicht so hochkritisch, dass man nicht mit der erreichbaren Geschwindigkeit arbeiten könnte. Die Performancesteigerung dank Deiner Hilfe bei der Generierung der Datenbasis ist wesentlich signifikanter.

Vielen Dank nochmal
Klaus

 

600s / 15s => eine Beschleunigung um den Faktor 40 ist doch ganz nett, zumal die Wirkungen der genannten Einzelmaßnahmen reproduzierbar sind, also bei anderen Aufgaben in gleicher Konstellation ähnlich wirken werden.

Nach oberflächlicher Betrachtung der Daten in tbl_einsatz gibt es, auf den Mitarbeiter bezogen, keine Überschneidungen bei den Einsätzen. Also genügt eine einfache Liste der Mitarbeiter zur Weiterverwendung. Dazu würde man unmittelbar eine tbl_Mitarbeiter heranziehen (Datenmodellierung lässt grüßen), oder man erzeugt als zweite Wahl diese Liste aus der tbl_Einsatz:
Code:

Erst diese Liste verwendet man nun in einer Folgeabfrage für die aufwändige Funktion. Das X ist da nur ein Tabellenalias. Eine Unterabfrage muss einen Namen bekommen, auch wenn man ihn nicht zwingend benutzen muss. Das X ist beliebig austauschbar, verzichtest Du auf eine Eigenbenennung, würde der Abfrageeditor einen kryptischen Alias einsetzen (der es nicht übersichtlicher macht).

Da befindest Du Dich in einer zahlreichen Gesellschaft. Leider, muss man sagen, da ich damit nur Entwickler meine, also jene, die Datenbanken erstellen.

Zur Verkettung von mehr als einem Feld müsste die Funktion ADOConcatColumn leicht modifiziert werden.

 

Hallo Eberhard,

Jetzt habe ich verstanden, was Du da gemacht hast. ...wieder was gelernt. *Smilie

...habe ich auch hinbekommen. Kann jetzt zwar keinen messbaren Zeitgewinn erkennen, aber ich akzeptiere es mal als die "technisch bessere Lösung".

Vielen Dank nochmal!

Gruß
Klaus