Office: (Office 2000) Extrem langsam, Win 7 64bit

Hallo Zusammen,
bei immer mehr Anwendern unserer umfangreichen Access 2000 Anwendung bekommen wir ein Geschwindigkeitsproblem.

Es tritt in Verbindung mit Windows 64 Bit (Frontend) und z.B. einen Small Business-Server 2011 (Backend) auf. Programmabläufe die mit einem Windows XP Client sehr schnell sind, werden mit Windows 7 64 Bit auf einmal unerträglich langsam. Es ist geradezu so als wenn das System teilweise festhängt. Im Taskmager ist bei den Verzögerungen kaum Aktivität festzustellen.

Ich habe schon tagelang gegoogelt und habe nirgendswo Abhilfe gefunden. Aber offensichtlich ist das Problem von der Access-Version unabhängig. Ich vermute das Problem irgendwo im Bereich der Jet-Engine in Verbindung mit Windows 7 64 Bit.

So Standardsachen wie Windows-Defender deaktivieren usw. habe ich schon gemacht.

:)

 

Hallo nochmal,

Zum Verdeutlichen des Problems habe ich eine kleine Testanwendung geschrieben.

Eine Frontend.mdb und eine Backend.mdb.
Die Backend.mdb wird auf einen Server abgelegt. Die Frontend.mdb wird auf einen Client-PC abgelegt.

In der Frontend.MDB wird eine Verknüpfung zu der Tabelle Rechnung innerhalb der Backend.mdb erstellt. Im Formular1 kann ein Test aufgerufen werden. Es werden 3 simple Abfragen geöffnet und wieder geschlossen und dabei die Zeit festgehalten. Meine Ergebnisse dabei waren:

Windows 7 Professional 32 Bit: 20 bis 30 Sekunden
Windows XP auf demselben PC als Virtuelle Maschine: unter 20 Sekunden
Windows 7 Home Edition 64 Bit (Intel Core i7, 8 GB RAM): über 450 Sekunden


http://www.pn-software.net/downloads...aenge/Test.zip

 

Moin,
unter Win7 Enterprise 64Bit meldet der Test 92 Sekunden. Wir haben hier allerdings ein recht flottes Netz.
Wieso hat das Backend mit der einen popeligen Tabelle eine Größe von 54 MB?
Auch durch Komprimieren nicht kleiner zu kriegen ...
maike

 

Ich habe die Datenbank mal bei mir laufen lassen:

Frontend auf WinXP in Virtuelle Maschine mit Access 2007
Backend auf Windows Server 2003

Laufzeit : 11,6 sec

Tip: mit dem Sysinternals Process Explorer nachsehen
wie schnell die Zugriffe auf den Server sind, denn das
hört mir doch ziemlich nach einem Netzwerkproblem der
Maschine an..

 

Weil diese "popelige" Tabelle 151 Felder ( unter anderem 8 Memo Felder, diverse Währungsfelder, etc ), und 25 Indizes hat.

Sprich: die Tabelle ist nicht normalisiert ....

 

Mit XP-Client hatte ich ja ähnliche Ergebnisse, unter 20 Sekunden (tatsächlich je nach Systemauslastung 8-18 Sekunden).

Die popelige Tabelle ist auch nur eine Tabelle von über 700 in unserer Software und dient als Beispiel. Es geht hier jetzt auch nicht darum diese Tabelle oder die 3 Abfragen zu optimieren. Ich suche nach einer Möglichkeit, dass unsere Anwendung auf einem Windows 7 64 Bit Client genauso schnell arbeitet, wie auf einen XP-Client.*frown.gif*


Die Arbeitsgeschwindigkeit ist unter XP sehr gut und unter Windows 7 64 Bit teilweise unerträglich langsam. Obwohl Windows 7 64 Bit Clients im allgemeinen hardwaretechnisch XP-Clients bei weiten überlegen sind.

 

Ich habe jetzt mal die Tests mal lokal mit erstaunlichen Ergebnissen durchgeführt.*entsetzt

Frontend und Backend in c:\Test:


Windows 7 Professional 32 Bit: 0,5 bis 35 Sekunden
Windows XP auf demselben PC als Virtuelle Maschine: 0,5 bis 2,5 Sekunden
Windows 7 Home Edition 64 Bit (Intel Core i7, 8 GB RAM): 15 bis 490Sekunden

Am Netz oder Server kann es also nicht liegen!

Ich hoffe das man in Windows 7 an irgendeiner Schraube noch drehen kann, aber an welcher?

 

Hallo Zusammen,

ich glaube jetzt habe ichs.

Eine kleine Einstellung in der Registry.

MaxBufferSize für die Jet-Engine auf 100000 (Dezimal) setzen. Tests mit 1000000 brachten auch keine Verbesserung.

Code:

Normaleweise wird dieser Wert automatisch verwaltet (bei MaxBufferSize = 0), offensichtlich gibt es bei Windows 7 dabei Probleme.

Meine neuen Testergebnisse mit Backend auf dem Server:

Windows 7 Professional 32 Bit: 0,4 bis 9 Sekunden
Windows 7 Home Edition 64 Bit (Intel Core i7, 8 GB RAM): 0,2 bis 7,8 Sekunden. *mrcool

 

MMh, ich habe den Test jetzt mal im Büro gemacht:
- Win7 Professional 64 bit -> Windows Server 2008 R2 : 7,4 sec
- Win7 Professional 64 bit -> Samba / Ubuntu Linux : 4,5 sec
- Win7 Professional 64 bit (lokal) : 0,8 sec


und MaxBufferSize steht auf "0" !

 

Und ich muss das trotzdem mal aufgreifen:

"dient als Beispiel." aber leider als schlechtes Beispiel *biggrin.gif*

weil bei diesen großen Tabllen zieht sich Access einmal die ganze Datenbank übers Netzwerk, bei mir waren es z.B. 51.000 Pakete mit 48 MByte,
werden denn die kompletten 58 MByte auch in der Anwendung genutzt ???
aRechnung_Taglohn gibt 19256 Datensätze zurück, werden jetzt wirklich 19256 Rechnungen ausgedruckt??

 

MaxBufferSize ist leider auch nicht die glücklich machende Lösung. In der echten Anwendung hatte ich schnell die Meldung nicht genügend Arbeitspeicher.

Ich habe den Wert dann auf 65536 (10000 hex) gesetzt, dann lief es sehr ausgewogen. Nur bei einer Funktion hatte ich dann noch die Speicher-Meldung (Eine sehr umfangreiche Funktion die beim ersten Start nach einem Update durchläuft ... evtl. neue Datenbankfelder anlegen, Druckeinstellungen wieder herstellen usw. ...).

Insgesamt ist mir die manuelle Einstellung von MaxBufferSize noch zu hackelig und anfällig (Die Anwendung ist bei über Tausend Anwendern im Einsatz und muss absolut stabil laufen). Was behindert Access bei der autom. Verwaltung des Speichers, dass die Geschwindigkeit so in den Keller geht.

 

Hallo
auch wenn Du Sagst:

Einige Optimierungs-Maßnahmen würde ich bei einem FE/BE trotzdem vornehmen. (wenigstens über Prüfen!)
dazu Lies Hier
http://dl.dropbox.com/u/46590638/ACC...unterlagen.zip
ab Seie : 58
z.b. Tabelle Optimieren , Permanente Verknüpfung mit der Daten–MDB zur Performance Verbesserung,
Seite 61 Alle Pfad-Namen ico, Bilder und ini Dateien auch nicht länger als 8 Zeichen

 

\@Ruedi

vielen Dank für die Tipps, eine wirklich beeindruckende Informationssammlung. Allerdings haben wir sämtliche Standardgeschichten bereits seit langem ausgereizt.

Die Veränderung von MaxBufferSize führt ja grundsätzlich zum Erfolg für eine schnelle Performance, ist aber vorsichtig zu dosieren. Wir werden jetzt eine Einstellmöglichkeit ins Programm einbauen, die erst am Ende des Programmstarts gesetzt wird, dann sind evtl. umfangreiche Update-Konvertierungen durchgelaufen.

z.B.
Code:

Ich hoffe das wir so zum Erfolg kommen. Es zählt ja nicht nur die Performace sondern auch die Stabilität eines Programmes.

Vieleicht hat ja jemand noch bessere Ideen.


Wer den Umfang der gesamten Anwendung wirklich mal sehen will:
http://www.pn-software.net/downloads...eta/hw2000.zip

Die Dateien einfach in ein Verzeichnis kopieren und die hw2000.mdb mit Access 2000 oder 2003 starten. Ohne Freischaltung ist das Programm 30 Tage lauffähig.

 

Hallo MOF-Freunde,
alte Hündchen leben länger...
Hatte das Geschwindigkeitsproblem mit Access 2003 unter W7(64), für das ich lange keine Lösung fand. Dann habe ich Horst Wessels Tipp mit der MaxBufferSize der Jet Engines ausprobiert.
Bei W7 stehen die Jet 2.0, 3.0 und 4.0 hier:
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Jet\4.0\Engines\
Habe bei allen dreien den Wert auf 100000 (hex) gestellt mit dem Erfolg, dass jetzt auch die langsamen DBs normal schnell schließen.
Die Werte standen vor meinen Änderungen auf:
Jet 2.0: 200
Jet 3.0: 0
Jet 4.0: 2710
Ich finde es extrem ärgerlich, dass Änderungen in Betriebssystemen solche unvorhergesehenen Folgen (und damit auch Kosten) beim User verursachen.
Aber - Ärgern verkürzt nur die eigene Lebensdauer.

Danke an Horst und alle anderen.
Mit herzlichen Grüßen
Friedhelm Achenbach

 

Hallo
und was da alles noch auf uns zukommt
Windows 8.1 etc. (Office 2013 ...)

schade dass das nich den guten Bill trift *boah *wink.gif*