Office: (Office 2013) Abfrage dauert sehr lange

Hallo

Ich habe in einer Excel-Datei eine Abfrage aus eine Access-Datenbank geschrieben. Diese funktioniert grundsätzlich auch.

Code:

Nun wollte ich die Abfragegeschwindigkeit getestet.

Ich habe an zwei PC's jeweils die Zeit der Abfrage getestet, als beide Dateien(Excel-Datei und Access-Datei) auf dem jeweiligen lokalen PC auf der
Festplatte gespeichert waren und als die beiden Dateien jeweils auf dem Netzwerkspeicher der Fritzbox gespeichert waren.

PC1 ist ein Desktop PC, der mit Windows7 und Office13 läuft.
PC2 ist ein Laptop, der mit Windows7 und Office07 läuft.

.......................................................................Abfrage von lokaler......................Abfrage von der
.............................................................................Festplatte..............................Fritzbox (Netzwerkspeicher)
.
PC1 mit Windows7 und Office13..................Abfragezeit 1 Sec..............................Abfragezeit 51 Min
.
PC2 mit Windows7 und Office07..................Abfragezeit 4 Sec..............................Abfragezeit 30 Sec

Meine Frage: kann sich jemand diesen krassen Zeitunterschied erklären?
PC1 ist bei der Abfrage von der Festplatte schneller als PC2 aber im Netzwert extrem viel langsamer. Ich habe auch schon die Anschlüsse der
PC's getauscht, das Ergebnis war gleich. Ich habe auch die Zeit gestoppt, wie lange es dauert, bis ich Daten auf den Netzwerkspeicher geschrieben habe.
Da gab es auch keine großen unterschiede zwischen den beiden PC's. Also an der Netzwerkverbindung liegt es eigentlich nicht.

Ich vermute, dass es am Office7 bzw. Office13 liegt.
Hat da jemand eine Erklärung, ob man das Problem beheben kann?

Gruß Faultier

:)

 

hier ist ein testcode zumm ausprobieren mit einem anderen datenbanktreiber (ace). wir haben mit einer ähnlichen konstellation (kein nas sondern netzwerkfreigabe per smb) gute ergebnisse erzielen können. passe deinen code einfach an und lass ihn laufen. meine testumgebeung: windows 8.1, excel 2016




Code:

 

Hallo rushifell,

Ich habe deinen Code getestet und habe leider keine Verbesserung erzielen können.
Gibt es einen Unterschied zwischen Office 2007 und Office 2013 das dieses Problem erklären könnte?
Oder was könnte ich noch testen?

Gruß Faultier

 

ich hab in einer virtuellen maschiene (win7 und office 2013 32bit) und dank fritzbox 7490 eine nas-test-umgebung aufgebaut und deinen code zum testen verwendet. leider kann ich keine performance-einbussen feststellen. weder bei deinem, noch bei meinem code ist eine auffällige reaktionszeit zu beobachten.

schau bitte mal, ob dein office auch die 32bit-version ist und welche treiber in den odbc-modul der systemsteuerung vorhanden sind.

 

Hallo,

wie ist die Fritzbox denn mit den Rechnern verbunden (Kabel, WLAN)?

Ich würde nach Benchmark-Software für NAS-Systeme im WWW suchen, um Netzwerkprobleme ausschließen zu können.

 

nun, dann hätte aber eigentlich in der anderen umgebung ähnliche zeiten gemessen werden müssen, oder?

mein client ist mit 1 gbit an der fritzbox per lan angebunden.

 

Hallo rushifell,

Also der PC1 hat Windows7 64 Bit und Office2013 ist auf jeden fall auch 64 Bit.
Beim PC2 ist Windows7 auch 64 Bit, das Office2007 weiß ich nicht genau. Wo kann man das nachschauen?

Wo finde ich das odbc-modul in der Systemsteuerung um die Treiber sehen zu können?

NACHTRAG:
Ok habe gerade im Internet gelesen, dass es für Office 2007 keine 64 Bit Version gibt.
Dann ist es um so seltsamer, dass die 32Bit Version die Abfrage schneller hinbekommt als Office mit 64Bit...


Hallo Nouba,

beiden PC's sind mit Kabel verbunden und beim Hochladen verschiedener Daten war die Hochladezeit an beiden PC's gleich.
Daher vermute ich, dass das Netzwerk nicht das Problem ist.

Groß Faultier

 

also ich würde jetzt folgendes tun: vbox, windows 7 64bit drauf, office 2013 32 bit drauf, messen.

 

Hallo rushifell,

nun habe ich das auf PC1 mit Office 2013 32Bit versucht aber an der langen Abfragezeit hat sich nichts geändert. ????

Dann habe ich auf PC1 Office2007 Installiert und plötzlich ging die Abfrage nur noch 30 Sec anstatt 50 Min.
Offensichtlich liegt das Problem nicht an der 32 oder 64 Bit-Version des Office Pakets sondern daran, ob man Office 2007 oder Office 2013 verwendet.
Jetzt wo man die Ursache kennt, wie löst man das Problem???

Gruß

 

bist du aus iregndeinem grund an das office 2013 gebunden? es wäre dann zwar immernoch keine ursache und damit eine lösung in sicht, aber es wäre ein produktiver status, oder?

ich suche mal, was ich über das problem im netz finden kann. melde mich.

nachtrag:
folgendes klingt superinteressant:https://accessexperts.com/blog/2011/...s-2007-solved/

lies bitte auch die antworten auf den artikel.

 

Beruflich bin ich an Office2013 gebunden....

Ich habe nun die Multicastnamensauflösung aktiviert, hat aber leider nichts an meinem Problem gelöst...

Gruß Faultier

 

Bei der sehr einfachen Abfragedefinition wären mir schon die 4 Sekunden unerträglich. Wieviele Hunderttausend Datensätze enthält die Tabelle?

Normales Handwerkszeug (sollte sowieso erledigt sein):
Code:

=> WHERE-Klausel statt HAVING
=> Feld Datum indiziert

 

Hallo ebs17,

Meine Datenbank enthält fast 2,5 Millionen Datensätze.
Dein SQL-Codevorschlag ist ca. 15% schneller.
Warum ist WHERE besser als HAVING

Gruß Faultier

 

WHERE filtert VOR der Gruppierung/Aggregierung, HAVING filtert NACH Gruppierung/Aggregierung.

Operationen wie JOIN oder GROUP BY sind gewichtiger als einfache Filteraktionen. Daher ist es regelmäßig sinnvoll, erst die Datenmenge zu reduzieren und die aufwändigere Operation dann mit der kleineren Datenmenge auszuführen.

HAVING sollte der Filterung auf Aggregate (Maximum, Minimum, Anzahl, Durchschnitt, Summe) vorbehalten bleiben. Der Abfrageeditor von Access produziert hier regelmäßig Mist, aber er dient neben der Erledigung von Routinearbeiten ja auch nur dazu, SQL-Unkundigen überhaupt zu funktionierenden Anweisungen zu verhelfen.
Allerdings wird in einigen Fällen der Jet-Optimierer das Problem selber lösen und ein HAVING als WHERE ausführen lassen, ein Blick in den Ablaufplan kann da Klarheit schaffen.

Die Frage nach der Indizierung hast Du nicht ignoriert?
Grundlagen - SQL ist leicht (8) - Index

 

Hallo ebs17,

nein die Frage nach der Indizierung habe ich nicht ignoriert da ich mich bei der Erstellung der Datenbank damit auseinander gesetzt habe.
Aber aufgrund deines erneuten Hinweises und des Links habe ich mir die Sache erneut angeschaut.
Ich hatte nur meinen Primärschlüssel ein Index zugewiesen bzw. wurde automatisch zugewiesen.

Ich habe deshalb dem Feld Datum den Index "Ja Duplikate möglich" zugewiesen und die Abfrage erneut getestet. Die Abfrage konnte ich nun von 3,5 Min auf 2 Sek reduzieren. das war echt beeindruckend.

So wie ich es in deinem Link verstanden habe, mach ein Index Sinn, wenn man viel Abfragen durchführt, aber weniger Sinn, wenn man häufig in die Datenbank neue Datensätze einfügt.

Nun schreibe ich täglich ca. 3000 Datensätze in meine DB. Natürlich tätige ich auch ein paar Abfragen oder lass die Datensätze überprüfen bevor ich sie anfüge.

Woher weiß man nun ob es Sinn mach, einen Index zu verwenden, wenn man es nicht mühsam testen will???

Gruß Faultier