![]() |
Datenbank: SQL Server • Version: ? • Zugriff über: Access
Gibt's bei Access auch Ausführungspläne?
Hallo,
ich habe hier eine lange bestehende Anwendung, wo in ein Access-Frontend Tabellen, die auf einem SQL-Server (als Backend) liegen, eingebunden sind. Hatte hier jetzt eine komplizierte Abfrage (viele Joins usw.) die eigentlich recht performant lief (<1s). Nun ist an einer der Tabellen im Join etwas geändert worden (keine Ahnung was). Nachdem diese Tabelle in Access im Verknüpfuungs-Manager aktualisiert wurde, braucht die gleiche Abfrage auf einmal mehr als 20 Sekunden. Wie kann ich dem auf die Spur kommen bzw. die Abfrage verbessern? Wie funktiert das überhaupt im Zusammenspiel Access<->SQL-Server. Führt Access die Abfragen aus (und optimiert die ggf.) oder wird das an den SQL-Server durchgereicht? Hat Access sowas wie einen Ausführungsplan und kann ich mir den angucken oder passiert das doch im SQL-Server, wie komme ich da an den Ausführungsplan? |
AW: Gibt's bei Access auch Ausführungspläne?
Vielleicht hilft das
![]() |
AW: Gibt's bei Access auch Ausführungspläne?
Hab den Artikel gerade erstmal nur überflogen, aber das scheint mir schon genau das zu sein, was ich gesucht habe. Werde ich dann heue Nachmittag mal etwas mit experimentieren. Danke baumina :thumb:
|
AW: Gibt's bei Access auch Ausführungspläne?
Was ist denn genau langsamer?
- eine Passthroughabfrage nach SQLServer? - eine heterogene Abfrage zwischen Accessdaten file und SQL Server`? - .. Die beiden wahrscheinlichsten Varianten: Die Abfrage wird auf SQL Server einfach langsamer ausgeführt und das kann Access nicht wegzaubern. Müsste einfach nachvollziehbar sein, neuer Join, fehlender Index oder sowas. Falls es eine Heterogene Abfrage ist, kann die mglw. nicht mehr (gut genug) remote aufgelöst werden. Also werden dann die Daten alle(!) nach Access runtergeladen (das dauert) und dann wird die heterogene Abfrage zu einer lokalen. |
AW: Gibt's bei Access auch Ausführungspläne?
Musste Passthroughabfrage erstmal googeln und denke, das ist es in unserem Fall nicht.
Wir haben die Tabellen als Veknüpfte Tabellen in Access und die Abfrage ist in Access selber. Vielleicht zur Abfrage, die wie gesagt selber nicht geändert wurde (nur die betroffenen Tabellen):
SQL-Code:
(keine Where-Bedingung ausser den Joins)!
Select "div. Felder von a,b,c"
From TabelleA a Left Join TabelleB b on .. Left Join TabelleC c on .. Union Select "div. Felder von a2,b,c" From TabelleA2 a2 Left Join TabelleB b on .. Left Join TabelleC c on .. Ich habe diese Mittlerweile optimiert (Laufzeit wieder <1s) zu:
SQL-Code:
Versuche aus Neugier aber immernoch auf das Problem zu kommen. Sprich nehme ich eine alte Access-Datei, wo TabelleB noch nicht mit dem Verknüfungs-Manager aktualisiert wurde, ist die Abfrage schnelle. Aktualisiere ich jetzt die Verknüpfung zu TabelleB ist die Abfrage langsam.
Select
div. Felder A,b,c From ( Select "div. Felder von a1" From TabelleA a1 Union Select div. Felder von a2 From TabelleA2 a2 ) as A Left Join TabelleB b on .. Left Join TabelleC c on .. |
AW: Gibt's bei Access auch Ausführungspläne?
Delphi-Quellcode:
sortiert, um eventuelle Dubletten in der Ergebnismenge zu entfernen.
Union
Können bei der Abfrage überhaupt Dubletten entstehen? Wenn grundsätzlich nein, dann
Delphi-Quellcode:
nehmen, spart die, in dem Fall, unnütze Sortierung. Und die kann bei großen Datenmengen schonmal ein bisserl dauern.
Union all
|
AW: Gibt's bei Access auch Ausführungspläne?
Zitat:
|
AW: Gibt's bei Access auch Ausführungspläne?
Zitat:
|
AW: Gibt's bei Access auch Ausführungspläne?
Zitat:
Mit passthrough könntest Du Erfolg haben. Auf der anderen Seite habe ich es oft genug erlebt, daß Access den 5..x Join in den falschen Hals bekommt und die Abfrage ewig läuft. da half nur alles neu aufzubauen. Gleiches gillt für Tabellen die in Access liegen (Artikelnummern) und die als Einschränkung der Serverdaten dienen. Da war es am besten, die lokale Tabelle erst zum Schluß zu joinen. (klingt fürchterlich und ist fürchterlich) Gruß k-H |
Alle Zeitangaben in WEZ +1. Es ist jetzt 10:51 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz