Live-Forum - Die aktuellen Beiträge
Datum
Titel
24.04.2024 19:29:30
24.04.2024 18:49:56
Anzeige
Archiv - Navigation
1336to1340
Aktuelles Verzeichnis
Verzeichnis Index
Übersicht Verzeichnisse
Vorheriger Thread
Rückwärts Blättern
Nächster Thread
Vorwärts blättern
Anzeige
HERBERS
Excel-Forum (Archiv)
20+ Jahre Excel-Kompetenz: Von Anwendern, für Anwender
Inhaltsverzeichnis

Excel zu langsam?

Excel zu langsam?
24.11.2013 17:02:23
Joe
Hallo,
ich habe eine Excel2003-Anwendung, die Daten aus Access für die weitere Bearbeitung in ein Excel-Sheet übernimmt. In meiner eigenen Systemumgebung sind beide Dateien im gleichen Verzeichnis lokal abgelegt, was zu Antwortzeiten von ca. 4,5 Sekunden führt. Meine User klagen nun darüber, dass bei Ihnen die Antwortzeiten bei gleichen Zugriffen über ihr Netzwerk 55 Sekunden und mehr betragen. Die User haben Office 2007.
- Woran kann das liegen?
- Wie kann man das beschleunigen?
- Spielt die unterschiedliche Excel-Version eine Rolle?

15
Beiträge zum Forumthread
Beiträge zu diesem Forumthread

Betreff
Datum
Anwender
Anzeige
AW: Excel zu langsam?
24.11.2013 18:10:14
Martin
Hallo Joe,
ohne deinen Makrocode zu kennen, ist eine Analyse sehr schwierig (...bzw. nicht möglich). Es gibt einige Möglichkeiten Makrocode zu optimieren, wie zum Beispiel:
- Zugriff auf die Access-Datenbank via Early Binding statt Late Binding
- Deaktivierung der Bildschirmaktualisierung
- vorübergehende Umschaltung auf manuelle Berechnung
- Auslesen der Access-Daten via SQL-Command
Bei der Umstellung von Excel 2003 auf 2007 wurde viel geändert. Die Zeilenanzahl wurde von 65.536 auf 1.048.576 und die Spaltenanzahl von 256 auf 16.384 erhöht. Selbstverständlich geht das und der wesentlich höhere Funktionsumfang zu Lasten der Performance, insbesondere wenn auch noch viele und komplexe Formeln in der betreffenden Arbeitsmappe enthalten sind.
Viele Grüße
Martin

Anzeige
AW: Excel zu langsam?
24.11.2013 19:34:03
Joe
Hallo Martin,
vielen Dank für die schnelle Antwort.
Einige Deiner Vorschläge hatte ich bereits vorweggenommen. So ist während der gesamten Prozedur die Bildschirmaktualisierung aus und der Berechnungsmodus auf xlManual.
Ich habe die Recordset-Variable vorher garnicht deklariert. Für den Zugriff stelle ich eine SQL-Abfrage zusammen und öffne das Recordset wie folgt:
Code

rec.Open sql, conn, adOpenKeyset                         ' Recordset-Objekt öffnen
For k = 1 To rec.Fields.Count - 1
ÜC_Array(1, k) = rec.Fields(k).Name                  ' Überschriften einlesen
Next k
Sheets("Tabelle2").Range("A3:IV3").Value = ÜC_Array()    ' Feldüberschriften übergeben
v_Anzahl1 = rec.RecordCount                              ' Anzahl Datensätze merken
Sheets("Tabelle2").Cells(4, 1).CopyFromRecordset rec     ' alle Datensätze übernehmen
rec.Close                                                ' Recordset-Objekt schließen
Was schlägst Du vor?
Viele Grüße
Joe

Anzeige
AW: Excel zu langsam?
24.11.2013 20:32:09
Martin
Hallo Joe,
dein Code sieht schon recht vernünftig aus, ich hätte mir aber das vollständige Makro gewünscht. Wie baust du die Verbindung zur Datenbank auf?
    'Early Binding:
Dim conn As New ADODB.Connection

oder

'Late Binding:
Dim conn As Object
Set conn = CreateObject("ADODB.Connection")
In jedem Fall ist Early Binding die schnellere Methode. Jedoch muss dazu im VBA-Editor ein Verweis auf die Microsoft ActiveX DataObjects (MSADO) gesetzt sein. Das spart gegenüber Late Binding schon einige Sekunden.
Dein verwendeter CursorType "adOpenKeyset" erfordert einen größeren Verwaltungsaufwand. Entferne den CursorType, dann wird das Recordset-Object automatisch auf eine möglichst effiziente Verwaltung optimiert (...oder setze stattdessen "adOpenForwardOnly" oder "adOpenDynamic" ein).
Also ich würde es so probieren:
    rec.Open Sql, conn                          ' Recordset-Objekt öffnen
For k = 1 To rec.Fields.Count - 1
ÜC_Array(1, k) = rec.Fields(k).Name     ' Überschriften einlesen
Next k
With Sheets("Tabelle2")
.Range("A3:IV3").Value = ÜC_Array()     ' Feldüberschriften übergeben
.Cells(4, 1).CopyFromRecordset rec      ' alle Datensätze übernehmen
End With
v_Anzahl1 = rec.RecordCount                 ' Anzahl Datensätze merken
rec.Close                                   ' Recordset-Objekt schließen
conn.Close                                  ' Connection schließen
Viele Grüße
Martin

Anzeige
AW: Excel zu langsam?
24.11.2013 21:39:26
Joe
Hallo Martin,
Danke erneut.
Ich habe auch das Objekt conn bisher nicht deklariert.
Ich öffne die Verbindung zur Datenquelle mit
Code

conn.Open "Provider=microsoft.jet.oledb.4.0;Data Source=" _
+ ThisWorkbook.Path + "\Datenquelle.MDB"
' Verbindung zur Datenbank
rec.Open sql, conn, adOpenKeyset                         ' Recordset-Objekt öffnen
For k = 1 To rec.Fields.Count - 1
ÜC_Array(1, k) = rec.Fields(k).Name                  ' Überschriften einlesen
Next k
Sheets("Tabelle2").Range("A3:IV3").Value = ÜC_Array()    ' Feldüberschriften übergeben
v_Anzahl1 = rec.RecordCount                              ' Anzahl Datensätze merken
Sheets("Tabelle2").Cells(4, 1).CopyFromRecordset rec     ' alle Datensätze übernehmen
rec.Close
conn.Close                                               ' Verbindung kappen
Ich ahne nun, dass diese fehlende Deklaration das Ganze langsam macht. Leider komme ich mit der Early Binding nicht klar.
Ich habs mal wie vorgeschlagen versucht. z.B so:

Dim conn As New ADODB.Connection
Set conn = ThisWorkbook.Path + "\Datenquelle.MDB"
Leider bekomme ich bei allen Versuchen, über Open oder Set eine Verbindung herzustellen verschiedene Fehlermeldungen.
Wie öffne ich im Rahmen der Early Binding die Connection zur Datenquelle.mdb bzw. dann das Recordset-Objekt? Wie bindet man dort die SQL-Query ein? Und was meinst Du mit "muss im VBA-Editor ein Verweis auf die Microsoft ActiveX DataObjects (MSADO) gesetzt sein"?
Bisher brauche ich das adOpenKeyset, da rec.RecordCount andernfalls immer mit -1 belegt ist. Möglicherweise löst sich dieser Punkt in Wohlgefallen auf, wenn ich die Early Binding hinbekomme.
Ich bitte Dich, Martin, also erneut um Deine Hilfe.
Viele Grüße
Joe

Anzeige
AW: Excel zu langsam?
24.11.2013 23:09:39
Martin
Hallo Joe,
eine fehlende Variablen-Deklaration ist zwar nicht schön, aber sollte auf die Performance keinen Einfluß haben. Du arbeitest bereits mit Early Binding und musst bereits einen Verweis auf Microsoft ActiveX DataObjects gesetzt haben, sonst hätte dein Code bislang nicht funktioniert.
Der Nachteil beim CursorType "adOpenForwardOnly" besteht darin, dass nur eine geringe Anzahl von Funktionen unterstützt wird (...wozu scheinbar leider auch "Fields.Count" gehört). Ich hoffe, dass die Überschriften mit "adOpenDynamic" bereits ausgelesen werden können (...und bei diesem CursorType ist der Verwaltungsaufwand auch noch relativ gering). Die Variablendeklaration muss so aussehen:

Dim conn As New Connection
Dim rec As New Recordset
Offen gesagt habe ich nicht das Gefühl, dass ich dir helfen konnte, denn du hast die Datenbakverbindung bereits mit Early Binding aufgebaut und der CursorType sollte keine so extrem hohe Zugriffszeit verursachen. Die Idee von Luschi ist gut. Liegt bei deinen Kunden die Access-Datenbank eventuell auf einem Netzwerkserver?
Viele Grüße
Martin

Anzeige
AW: Excel zu langsam?
24.11.2013 21:59:58
Luschi
Hallo Joe,
da ich vermute, das Du alles von Excel aus steuerst und die SQL-Abfrage in Excel zusammenstellst, ist die Access-DB auf dem Netzlaufwerk und ein eventuell langsames Netzwerk der Knackpunkt und Engpaß.
Schickt man Abfragen vom lokalen Excel an die Netz-Access-DB, dann schickt Access von ALLEN angesprochenen Tabellen ALLE Daten über das Netzwerk und erst Excel auf dem lokalen Rechner wertet die Where-Bedingung aus. Das heißt, es kommen viel mehr Daten über das Netzwerk als dann am Bildschrim in der Excel-Tabelle angezeigt werden. Denn Access ist eben kein SQL-Server, dier erst die Daten mittels Auswertung der Where-Bedingung zusammenstellt und dann die Daten über das Netzwerk auf die Reise schickt.
Ich mache das immer so:
- per ADOX schreibe ich den SQL-Befehl in eine Dummy-Abfrage in der Netz-Access-DB
- per ADODB rufe ich dann alle Datensätze dieser Dummy-Abfrage ab
- Voraussetzung ist aber, daß es die Berechtigung gibt, diese Dummyabfrage inhaltlich zu ändern.
Hier mal ein Beispiel: https://www.herber.de/bbs/user/88237.zip
Gruß von Luschi
aus klein-Paris

Anzeige
AW: Excel zu langsam?
25.11.2013 00:00:54
Martin
Hallo Luschi,
dein Makro "GetMoreSpeed" finde ich sehr ansprechend und gut gelöst. Auch die Code-Kommentierung gefällt mit sehr. Lediglich die Variablen-Bezeichnung finde ich etwas ungünstig (z.B. würde ich statt "ok" lieber "blnIsDummy" wählen, auch wenn es mehr Text ist).
Viele Grüße
Martin

AW: Excel zu langsam?
25.11.2013 05:06:02
Luschi
Hallo Martin,
ich weiß, daß meine Vba-Variablen-Bezeichnungen nie & nimmer der 'ungarischen Notation' entsprechen, aber in jedem M$-Hilfe-Code wird ebenfalls dagegen verstoßen.
Da ich sehr viel in VB.Net mache und alle in 1 Block definierten Variablen nach Blockende doch wieder Schall & Rauch sind, kann ich mich daran einfach nicht gewöhnen - aber Deine Kritik ist berechtigt.
Gruß und 1 schönen Wochenstart wünscht Luschi
aus klein-Paris

Anzeige
Aber Luschi, eine Kritik, die sich auf ...
25.11.2013 16:24:23
Luc:-?
…fehlende oder nicht korrekte UN bezieht, ist völlig unberechtigt, da die UN bei keiner PgmierSprache Standard ist noch jemals sein kann, da ihre Anwendung gg ein wesentl Prinzip aller Namensgebung verstößt, nämlich, vom Inhalt unabhängig zu sein. Davon sind natürlich keine Namensgebungsregelungen betroffen, die in Absprache in einem PgmiererTeam getroffen wurden. Derartige NamensKonventionen sind üblich, die UN nur ein Vorschlag dazu.
Leute, die das grdsätzlich verwenden zu müssen meinen, wollen oft so nur den Anschein von Professionalität erwecken. Allerdings hat Martin in einem recht, isDummy wäre besser als nur ok, das bln davor aber völlig überflüssig, denn es ist ja wohl irgendwie schizophren, die TypDeklaration als Namensbestandteil zu wiederholen. Selbst die UN ieS hatte hier den Verwendungszweck, nicht den DatenTyp vorgeschlagen.
Gruß Luc :-?

Anzeige
AW: Excel zu langsam?
25.11.2013 18:01:23
Joe
Hallo Luschi,
vielen Dank für Deinen Vorschlag und das beigelegte Muster.
Auf den ersten Blick fand ich es klasse! Allerdings kommen mir inzwischen Zweifel: Auf meine Anwendung greifen eine ganze Reihe von Usern (teils gleichzeitig) zu. Solange ich aus der Datenquelle nur gelesen habe, war das kein Problem. Wenn ich Deinen Vorschlag richtig verstanden habe, modifizierst Du von Excel aus die Abfrage in Access. Führt es nicht zu Schwierigkeiten, wenn mehrere User teils gleichzeitig über das Netzwerk in die Access-Abfrage schreiben?
Hier wäre ich für einen Tipp dankbar.
Viele Grüße
Joe

Anzeige
AW: Excel zu langsam?
26.11.2013 05:17:05
Luschi
Hallo Joe,
mein Beispiel ist ja nur der Anfang, um zu zeigen, wie man da ran gehen sollte. Bei mir hat jeder User eine eigene Abfrage, die er dann inhaltlich per ADOX verändert - abhängig von seinem Usernamen im Netzwerk. Beispiel folgt.
Gruß von Luschi
aus klein-Paris

AW: Excel zu langsam?
27.11.2013 16:46:43
Joe
Hallo Luschi,
ich muss Dir zu meinen Mengengerüsten noch ein paar Daten übermitteln.
Meine Access-Datenbank umfasst 70 MB. Derzeit greifen knapp 160 User mehr oder weniger häufig auf mein Excel-Tool zu. In einzelnen Aktionen holen sich die User aus 10 verschiedenen Access-Tabellen jeweils wenige Datensätze (bis zu 60, meist jedoch nur 1 bis 15) heraus. Die einzelnen Tabellen haben bis zu 60.000 Datensätze und bis zu 120 Felder. Werden die kompletten Access-Tabellen erst mal an Excel zur weiteren Verarbeitung übertragen, so sind das schon ordentlich große Datenmengen.
Deshalb finde ich Deine Idee, die Abfrage in Access laufen zu lassen und nur die wenigen Ergebnisdatensätze zu übertragen, sehr gut. Ich zweifle jedoch, ob es Sinn macht, ca. 1.600 Abfragen für alle User vorzuhalten. Evtl. können wir diese Access-Abfragen beim ersten Zugriff userbezogen mit festen Namenskonventionen anlegen und beim Verlassen meines Tools wieder userbezogen löschen. Geht das mit ADOX? Wenn ja, wie kann ich die neu generierten, "temporären" Abfragen wieder aus Excel heraus löschen?
Ich hab mal folgendes gefunden, bekomme es aber nicht gebacken.
Code

Dim rs As DAO.Recordset
Set rs = DBEngine(0)(0).OpenRecordset("SELECT [Name] FROM MSysObjects" & _
" WHERE Type = 5")
Do While Not rs.EOF
DoCmd.DeleteObject acQuery, rs!Name
rs.MoveNext
Loop
rs.Close: Set rs = Nothing

Viele Grüße nach klein-Paris
Joe

AW: Excel zu langsam?
28.11.2013 09:30:05
Luschi
Hallo Joe,
ich habe mein vorheriges Beispiel so abgeändert, daß jetzt für jeden User eine eigene Abfrage erstellt wird, die sich bildet aus Präfix 'qyr_' und dem angemeldeten Usernamen im Netzwerk.
Damit kommt sich kein User mehr in die Quere.
Da ADODB & ADOX seit Windows2000 vom Betriebssystem bereit gestellt wird, können damit auch Exceluser mit dieser Methodik arbeiten, ohne as auf ihrem Arbeits-PC Access installiert ist.
Natürlich werden Deine Abfragen komplizierter aufgebaut sein als mein kleines Beispiel, aber das Prinzig bleibt das Gleiche. Ob es Störeinflüsse gibt, wenn 160 User gleichzeitig so eine Abfrage ausführen habe ich nicht getestet.
https://www.herber.de/bbs/user/88283.zip
Gruß von Luschi
aus klein-Paris

AW: Excel zu langsam?
28.11.2013 17:59:24
Joe
Danke Luschi!!!

AW: Excel zu langsam?
28.11.2013 20:47:09
Luschi
Hallo Joe,
es wäre für mich sehr interessant zu erfahren, wie sich dieses Verfahren in der Praxis tatsächlich auswirkt.
Gruß von Luschi
aus klein-Paris

Beliebteste Forumthreads (12 Monate)

Anzeige

Beliebteste Forumthreads (12 Monate)

Anzeige
Anzeige
Anzeige