Abfrage durch Parameter langsamer?

Hallo zusammen

ich habe hier eine Abfrage wo ich nach Datum selektiere. Die Tabelle hat einige Millionen Datensätze und ist aufs Datum optimiert.
Also

>=#01.01.2008# Und <=#31.01.2008#

Das geht ruckzuck.. ca 3sek

Schreibe ich jedoch

>=[begin] Und <=[end]

und fülle die Werte aus, dauerts über eine Minute. Die Abfrage starte ich direkt per Mausklick.

Woran kann dies nun liegen? Akzeptiert er die Eingaben nicht als Datum?

thx4help

Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben

Content-ID: 103299

Url: https://administrator.de/forum/abfrage-durch-parameter-langsamer-103299.html

Ausgedruckt am: 27.04.2025 um 09:04 Uhr

10 Kommentare

Neuester Kommentar

Es würde helfen, die ganze Abfrage zu sehen.

Aber mal so ins Blaue hinein:
Kann es sein, daß [begin] und [end] Spalten in der Tabelle sind und Du damit Access zwingst für jede Zeile in der Tabelle einen neuen Vergleich zu machen da möglicherweise in jeder Zeile die Werte von Begin und End anders sind?
Das ist natürlich aufwendiger als einfach nur einen festen Bereich aus der DB zu selektieren.

Nein sind keine Spaltennamen.

Die Abfragen wäre zb so (mal ein wenig verkürzt):

SELECT PRUEFSTART
FROM TBL
WHERE (((TBL.PRUEFSTART)>=#11/28/2008# And (TBL.PRUEFSTART)<=#12/3/2008#));

SELECT PRUEFSTART
FROM TBL
WHERE (((TBL.PRUEFSTART)>=[begin] And (TBL.PRUEFSTART)<=[end]));

Also wie zu sehen ist ändert sihc die Abfrage nicht wirklich. Dennoch scheint es nicht zu klappen.
Das Feld PRUEFSTART hat übrigens Werte im Format TT.MM.YYYY SS:MM:SS also zb 01.01.2008 13:50:15

Als Eingabe für die Parameter ist egal ob ich die Uhrzeit mit reinschreibe oder nur das Datum.

Ich finde, das sollte funktionieren.
Falls Access Proble beim Konvertieren der Variablen in ein Datum hat, könnte man mal folgendes ausprobieren:

SELECT PRUEFSTART
FROM TBL
WHERE (((TBL.PRUEFSTART)>=CDate([begin]) And (TBL.PRUEFSTART)<=CDate([end])));

Aber eigentlich finde ich auch, daß es da keinen Unterschied geben sollte.

Leider kein Unterschied, dauert auch ewig.
Ist mir unverständlich wieso.. der muss doch den SQL nach Eingabe der Parameter genauso schreiben wie oben und dann ausführen...

Habe auch versucht als Parameter dann sowas wie #01.01.2008# einzugeben, also mit # aber geht nicht.
Auch in SQL dann statt [begin] ein #[begin]# funktioniert nicht.

Als Ursache bleibt eigentlich dann nur noch, daß Access bei Verwendung von Variablen nicht erkennt, daß er einen passenden Index hat und auf einen Full Table Scan umschwenkt.
Auf einem SQL Server könnte man das mit dem Query Optimizer rauskriegen, bei Access kenne ich keine Möglichkeit rauszubekommen was er tatsächlich macht oder in die Indexverwendung einzugreifen.

Moin fiacyberz,

Du darfst nicht immer so ablehnend mit diesem M$-Geraffel umgehen
- verwende ruhig auch mal zumindest die dokumentierten Features.

Deklariere die Eingabeparameter "begin" und "end" in der Abfrage.

Dokumentierte Syntax:

PARAMETERS begin date, end date;
SELECT PRUEFSTART
FROM TBL
WHERE (((TBL.PRUEFSTART)>=[begin] And (TBL.PRUEFSTART)<=[end]));

P.S. Ich würde NICHT Worte wie "begin" und "end" als Variablennamen in dürftig dokumentierten Umgebungen wählen.
Nimm lieber die deutschen Worte "Beginn" und "Ende" oder aber so etwas wie "dBegin" und "dEnd".

Grüße
Biber

Der Zugriff geht per ODBC auf eine Oracle DB.
Von daher kann ich da wenig sehen und machen habe dort keinen Zugriff

Habe das Ganze nun mal per VBA gemacht, sprich erzeuge die Abfrage in VBA und habe somit die Variable dort umgewandelt und läuft so wunderbar.
Nur würde die Abfrage lieber direkt gespeichert haben, damit mans besser ändern kann.

Wieso ablehend? Bin ich doch gar nicht.

Parameters kannte ich noch gar nicht, bringt aber leider keine Änderung, auch beginn statt begin ändert nichts.

Wie gesagt über VBA klappts wunderbar, weil ich da die Parameter ja direkt richtig umwandel und dann die Abfrage per SQL Befehl speichern kann. Aber die liegt dann eben in VBA und eine schnelle Änderung ist da nicht so leicht da man immer in den Code muss.

Moin fiacyberz,

wenn es dann über dieses dynamische SQL zu lange dauert, dann mach doch aus dieser Winz-Abfrage eine Stored Procedure mit zwei Parametern dBegin/dEnd, die das Ganze dann serverseitig abfackelt.
Dann ist die Abfrage kompiliert, oprimiert und ohnehin 2000x schneller, als Du sie vom Client aus jemals abschiessen kannst.

Grüße
Biber

Stored Procedure läuft auf den Server, richtig? Da habe ich leider keinen Zugriff drauf.
Könnte ich evtl. bekommen, jedoch ist das System was ich grad erstelle nur eine Art Testsystem und von daher werde ich dafür wohl nicht die Rechte bekommen auf dem Server was zu machen denke ich und so nötig wäre es hierfür dann wohl doch nicht.

Wäre halt ein Nice-To-Have wenn ich die Abfrage direkt mit Access-Mitteln (easy) bearbeiten könnte ohne in VBA Code zu gehen. Aber funktioniert so natürlich auch.

Werde das Problem für mich erstmal abschliessen, vielleicht finde ich ja irgendwann noch eine Erklärung warum es mit Parametern langsamer ist.

Frage Microsoft Office Microsoft

Heiß diskutiert