Office: (Office 2010) Dlookup mit MAX

db.Execute / DoCmd.RunSQL ... verwendet man für Aktionsabfragen, nicht für Auswahlabfragen.

Eine nicht funktionierende Abfrage bessert man nicht, indem man sie nach VBA überträgt, man gewinnt allerdings zusätzliche Fehlermöglichkeiten.

Apropos nichtfunktionierend bzw. langsam: Zur Auswertung der gezeigten 437 Datensätze gibt es bei mir keine sichtbare Verzögerung bei der Ausführung der Abfrage.

PS: Die fehlende schließende Klammer ist in der Tat verloren gegangen.

 

Danke für eure Antworten.*Smilie
ebs17 stimmt, die Test DB funktioniert. Sie enthält weniger Spalten.
ich vermute mal das es an einer bestimmten Spalte liegt bzw. Daten enthält die Access in die Knie zwingt.
Ich werde von der Test DB ausgehen und immer nur eine Spalte zum Import hinzufügen um festzustellen ab wann Access nicht mehr will. Melde mich dann, sobald ich die Spalte gefunden habe bzw. ob es an der Anzahl von Spalten liegt.
Gruß Gerhard

 

Das klingt dann etwas anders als unendliche Laufzeiten (bei 20 min abgebrochen).

Einen Vorschlag sollte man zur Übersicht als solchen beurteilen und nicht mit zusätzlichen eigenen (fehlerbehafteten) Garnierungen und Ergänzungen.

 

Hallo Ebs17,
warum? nun ich habe in der letzen Woche einmal den Arbeitsspeicher von 4GB auf 6GB aufrüsten lassen.
Nach Ausführung deiner SQL kam das Ergebnis nach 15min. Dachte schon das wäre die Lösung gewesen. Jedoch als ich bei der Abfrage auf den letzen DS scrollen wollte, hängte sich Access wieder auf.
Sind 100.000 DS x 58 Spalten zuviel für Access? Ich habe keine Antwort darauf. Oder liegt es an den Programmen die im Hintergrund laufen? Bei einen Firmenlaptop hat man nicht allzuviele Möglichkeiten etwas zu Experementieren. Auf jedenfall Danke ich dir für die Zahlreiche Hilfe. Wenn es nicht anders möglich ist muss ich kleinere Datenpakete verarbeiten.
PS: Die Demo diente um die Abfragekriteruim zu zeigen. Die restlichen Spalten die nicht in der Demo sind, dienen nur als Wertanzeige. Und deine SQL funktioniert auch einwandfrei. Nur mit der Datenmenge hat es etwas zu tun, daher wurde die Abfrage ausgeführt auch wenn es 15min. dauerte und mit 6GB.
Gruß Gerhard

 

Nein.

Die zusätzlichen Spalten werden nur von der äußeren Abfrage angezeigt (und nicht irgendwie verarbeitet) und sollten nur einen geringen Einfluss auf Laufzeiten haben. Trotzdem sollte man sich auf Notwendiges beschränken, zumal die Feldanzahl der Zieltabelle wohl noch immer etwas kleiner ist.

Datenmenge spielt natürlich eine Rolle, und 100k Datensätze ist eine andere Zahl als 437, und möglicherweise geht man die Besteigung eines Berges anders an als die Besteigung eines Maulwurfshügels. Allerdings sind 100k Datensätze noch ein überschaubarer Berg für Access und kein Mt. Everest.

Die Abfrage in #41 ist einigermaßen aufwändig (Gruppierungen, Filterungen, Sortierungen, Verknüpfungen), aber wohl aus funktionalen Gründen in dieser Form notwendig (vielleicht gibt es da auch noch Optimierungsmöglichkeiten, die ich nicht sehe).
Erstes Mittel für eine Laufzeitverkürzung wäre Indexnutzung. In einer Textdatei ist aber nichts indizierbar. Also wäre es einen Versuch wert, die Texttabelle in eine Accesstabelle zu importieren und danach maßgebliche Felder darin zu indizieren. Die gleiche Abfrage auf diese Tabelle sollte dann wesentlich schneller laufen, und das Gesamtpaket Import+Indizierung+Abfrage eigentlich auch.

Eine solche Temp-Tabelle (100k) würde man aber weder in seinem Backend als auch nicht in seinem Frontend führen, sondern besser in einem zusätzlichen Temp-Backend.

Bezüglich RAM-Aufrüstung: Viel verfügbarer Speicher ist für Datenbankarbeit immer gut. Allerdings muss der Speicher auch nutzbar sein. Da gibt es auch einige Abhängigkeiten zur Hardware, zum Betriebssystem und den Anwendungsprogrammen.

 

Diese Idee finde ich sehr gut und werde es so bald wie möglich durchführen und melde mich sobald ich Ergebnisse habe. Es kann etwas dauern, da ich jetzt ein anderes Projekt vorziehen musste.
PS:Werde es zwischen den Projekt durchführen. Danke Ebs17.
Gruß Gerhard

 

Als mögliche zusätzliche Schraube:
Wenn man schon mit der temporären Speicherung von Zwischenergebnissen arbeitet (den Import von CSV-Daten in eine Accesstabelle zähle ich dazu), könnte man auch das Abfrageergebnis der Abfrage lt. #39 als Tabelle speichen (und indizieren) und dann darauf nur die aufbauende Abfrage ausführen.

Als wiederholten Hinweis:
Der Einfachheit halber und zum Testen könnte man diese zusätzlichen Temp-Tabellen im Frontend erzeugen. Für einen ernsthaften Dauerbetrieb sollte man aber auf ein Temp-Backend ausweichen, um das Aufblähen der eigenen Anwendung zu vermeiden. Ansätze dafür finden sich hier:
Acc2007 - SKAT - Abfrage mit Streichresultaten
oder etwas komfortabler
Acc2003 - Neue DB temporär erzeugen

 

Hallo Ebs17,
ich habe deinen Vorschlag getestet in dem ich die Daten importierte und die sie Spalten mit den Suchparametern auf Indiziert (duplikat möglich) gesetzt.
danach deine Abfrage ausgeführt und in wenigen Minuten war das Ergebnis da. *Smilie Die Abfrage hat beim srollen immer wieder gestockt bis ich den letzten DS erreicht hatte, danach konnte ich sie flüssig durchsehen.
ich werde also per VBA die Daten importieren, indizieren, abfrage erstellen und diese in die Stammtabelle übertragen. Aber das muss ich später durchfühhren, bis ich mit dem aktuellen Projekt durch bin.
Obwohl dieses Projekt ein Kinderspiel sein sollte funktioniert es nicht so wie es soll. Aber dazu habe ich einen eigenen Tread eröffnet. http://www.ms-office-forum.net/forum...19#post1468419
ich denke das ich mit den Platzhalter falsch handle.*grins

Werde aber hier wieder Posten, sobald ich dieses Projekt weiter bearbeite. Danke nochmals für die Hilfe.
Gruß Gerhard

 

Hallo Ebs17,
auch in diesem Thema wird sich was tun. Nicht in meiner DB sondern man hat beschlossen im SAP eine Tabelle zu schreiben. Es wird sich nicht viel ändern jedoch die DS schrumpfen zumindest auf 2k. Aber bis es soweit ist, wird es einige Zeit dauern. Man kann mir nicht sagen wenn es fertig ist da auch andere Funktionen für den Betrieb geändert und angepasst werden.
Ich Danke dir auch hier für die Zahlreiche Hilfe und da dieses Projekt einmal stillsteht werde ich bei dem neuen weitermachen.
Gruß Gerhard
PS: Ich versuche immer noch Anhand deines Code die Zusammenhänge zu verstehen wie du die Abfragen in SQL erstellst. Aber ich Versuch es weiter.*Smilie