Zeitverhalten einer join Abfrage

[idefix2]

Ich kann das leider nur bestätigen. Aber hier handelt es sich um ein uraltes Projekt (in Delphi 5 geschrieben) mit über 1.000.000 Zeilen, zum Teil mit eingebundenen Fremdkomponenten, die es längst nicht mehr zu kaufen gibt. Freiwillig stelle ich das nicht um.

[jobo]

Also sicherheitshalber:
Fremdschlüssel B_NR = Primary Key = indiziert?

Ich hab gestern irgendwo gelesen, dass Access offenbar wirklich nicht in der Lage ist, bei stacked queries eine "vorgegebene" Reihenfolge einzuhalten bzw. sich eine brauchbare auszudenken.
Dennoch, hast Du mal etwas mit anderen Verfahren gespielt, z.B. "TOP 1" Aggregat? Ist natürlich unsinnig, könnte dem "Query Optimizer" aber vlt auf die Sprünge helfen. Mglw. gibt's noch andere tolle Krücken, die man auspobieren können.

[idefix2]

Ja, natürlich indiziert, sonst würde ja der Kunstgriff mit der extra Tabelle auch nichts bringen. Das Problem ist, dass die Access Syntax anscheinend kein Join mit dem Ergebnis eines Select vorsieht.
Und bei einer anderen Query, in die mehr Tabellen involviert sind, versagt jetzt der Trick auch, da bekomme ich die Fehlermeldung, dass die On-Klausel auf zu viele verschiedene Tabellen zugreift (es sind mit mit meiner Extra Tabelle genau 5 Tabellen ), und beim direkten Probieren der Query in Excel von der Excel Hilfe die Empfehlung, WHERE statt ON zu verwenden

[jobo]

Also "natürlich" mit Index ist okay, manchmal glaubt man ja auch nur, es sei ein Index drauf.
Subselects (geklammert) sollten eigentlich gehen, natürlich mit Table Alias!
"Where" ist ja auch nicht schlimm, nur wage ich zu bezweifeln, dass es dazu unter Access eine Notation für "outer" gibt.

[idefix2]

Das Problem ist ja, dass die Abfrage mit where extrem langsam wird, weil er zuerst die Riesentabelle aufbaut und danach selektiert.
Mit der ON Klausel wird der eine Datensatz gleich beim Join herausselektiert, weil die linke Tabelle nur aus einem Datensatz besteht, und nur dieses kleine Ergebnis wird mit einer Reihe von anderen Tabellen gejoint. Bei einem brauchbaren Query-Optimierer, wie ihn jede halbwegs moderne SQL Datenabnk hat, wäre das ganze Theater nicht nötig.
Ich gehe davon aus, dass eine neuere Access-Version das besser machen würde, aber die Umstellung des ganzen Delphi-5 Projekts auf eine neue Access-Version ist mir zu viel Aufwand.

[mkinzler]

Wenn ich Umsteigen würde, würde ich gleich ganz von Access weg wechseln

[Dejan Vu]

Wenn man die Sofware rein zufällig etwas strukturiert hätte, könnte man mit moderatem Aufwand umsteigen. Ich vermute, es wird mit ADO gearbeitet, dann bietet sich der MS SQL-Server (Express) an.

[RoadR69]

Also ich habe mir mal eine Beispieltabelle in meinem Access angelegt mit jeweils der doppelten Anzahl von Datensätzen ...
Ausführungszeit für die Orginal-Abfrage: sofort da, nicht messbar ...

Auch die 2. Abfrage läuft, welche natürlich etwas besser formuliert ist und mit Einfügen von "AS" (Access will das halt so...) läuft die auch.

select
A.*, B.*
from
( select * from A where A.A_Nr=1785) as A
left join B on A.B_Nr=B.B_Nr;

[Dejan Vu]

Probieren ist immer besser als mutmaßen.

Dann liegt es wohl an etwas Anderem.

[jobo]

Zitat von RoadR69:

Also ich habe mir mal eine Beispieltabelle in meinem Access angelegt mit jeweils der doppelten Anzahl von Datensätzen ...
Ausführungszeit für die Orginal-Abfrage: sofort da, nicht messbar ...

Auch die 2. Abfrage läuft, welche natürlich etwas besser formuliert ist und mit Einfügen von "AS" (Access will das halt so...) läuft die auch.

Klingt plausibel. Mich hat es gewundert, dass sowas simples nicht geht. Access ist keine Wundersoftware, aber sowas könnten sie können.
Da wäre aber eine wichtige Sache, welche Version ist das?
Dann ist da auch noch dieses ominöse Framwork in das "die Abfrage reingeht". Vielleicht ist das der Übeltäter.