Office: (Office 2003) Access-Datenbank nach Windows 7-Upgrade langsam

Welchen MSSQL-ODBC-Treiber setzt du überhaupt ein?
Ich nutze den, der bei den MDAC dabei ist.

Vielleicht liegt es aber - wie von dir schon einmal vermutet - am DSN.
Hast du die Verknüpfung schon mal ohne DSN probiert?
... Connectionstring sieht dann ungefähr so aus:
Code:

Details: ConnectionStrings.com - Forgot that connection string? Get it here!

Zur Sicherheit könntest du auch einmal in der verknüpften Tabelle prüfen, ob noch alle Indizes bekannt sind.

@Ruedi:

Ich verstand Caro-Toby so, dass er einen MSSQL-Server als DBMS einsetzt und keine Access/Jet-BE nutzt.

 

\@josef !!! ja mein string sieht genau so aus (etwas ähnlich)

die DSN scheint echt egal zu seine
jetzt kommts
der Tabellenverknüpfungsmanager (alle tabellen aktualiesieren) ist gefühlt viel schneller.

auch reine Tabellenabfragen scheinen schneller ausgeführt zu werden

nur bei Leftjoins und bei Ufos bzw Kontrollkästchen die sich im Form befinden
geht es langsam
ufos gehen langsamer auf – kontrllkästchen erscheinen sequentiell

den genauen Prozeß (also wo die funktionenn beim Stempeln wirklich langsamer sind. versuche ich noch einzugrenzen.)

reine SQL statements gehen schneller als bei XP

habe das Programm hingehend seiner Requerys noch mal derbe verschlankt - bringt auf jedenfall was bei Formularanzeigen - das bring allerdings auch was auf dem XP Rechner so daß der Gravierende Performance unterschiede immer noch starkt spürbar ist.

Dann habe ich noch di benutzerrechte uaf Null sicherheit gestellt
Und habe auch access im XP kompatibilitätsmodus fahren lassen (PS da ging es etwas flüssiger zu ) aber das ständige aufgepoppe von Warnmeldungen hat mich dann doch etwas genervt.

Lösung momentan
Neben meinem Rechner kommt ein 2ter rechner mit xp auf den ich remotemässig zugreiffe
Alles andere ist zeitverschwendung
Resume:
NEVER CHANGE A RUNING SYSTEM!!!!!!
In 10 Jahren haben alle Rechner WIN 7 bzw 64 BIT und dann muss ich mir was neues ausdenken.wer weiß vielleicht gibt’s dann kein Access mehr und wir loggen uns beim Betreten des Firmengeländes über unseren RIF oder Blutoth chip ein der uns die Arbeitsschritte ins Hirn Suggeriert-


Und gezahlt wird Eh in Ziggaretten bzw Butter Währung weils den Euro nur noch im Museum zu bestauenn gibt als Größtes gescheitetes Experiment nach Windows Vista

 

Nur zur Sicherheit: Wurde möglicherweise der PK beim Verknüpfen der Tabellen nicht erkannt? Ich nehme zwar an, dass du das bestimmt schon geprüft hast, aber sicher ist sicher. *wink.gif*

Und: Da du Access bestimmt neu installiert hast: die Oberbremse Objektnamen-Autokorrektur ist aber schon deaktiviert, oder?

Hast du den Virenscanner mittlerweile ausgeschlossen?

.. oder eine grundsätzliche Verbesserung an der Anwendung bzw. ein Lerneffekt. *Smilie

Ich kann nur wiederholen, dass ich zw. WinXP und Win7 keinen Unterschied bemerke. Also muss bei deiner Installation oder an deiner Anwendung etwas nicht passen.


mfg
Josef

 

\@Josef
Was soll ich machen
Lernefekt hin oder her - so wie es mal war läuft es nichtmehr
irgendwann ist mal gut - da muss man dinge einfach so nehemn wie sie sind -
(objektnamen autokorrektur - Rechtschreibeung etc - alles raus)
PK (also der Schlüssel ist da :-) )

ich habe sogar eine Leere Access datenbank erstellt und alle objekte per Drag & Drop die Abfragen, Forms, Module -in die neue gezogen - Alle Tabellen gelöscht und auf dem WIN 7 Rechner neu eingebunden - (das ist ne wunderlösung bei korrupten Datenbanken -
NIX

ich glaube es liegt an DAO ich mus auf ADO umschwenken oder noch mehr auf dem Server machen lassen - (besonders die Zeitdinger sind aufwendig)

SChnelligkeit versus Redundanz - das alte thema

ih beleibe dabei. ich verschwende keine Zeit merh in die neuprogramierung - weil irgendwann ein patch kommt und alles ist gut..............(und wenn du denkst es geht nicht merh - kommt von irgendwo so ein Patch daher)

ich bleibe bei remote und nehem WIN 7 für alles andere (PS ich müsstem mir auch ne neue telefonanlage kaufen weil ALLE meine Systemtelefone nicht 64 Bit tauglich sind - LOL - (PX721) und es keine Tapi Treiber dafür gibt (geben wird) Da ein neues Systemtelfon über 100 Euro kostet werde ich nicht alle austauschen ....- also WIN7 - erstmal Ohne mich - Zuhause als Spielzeig Toll - in der Firma zu teuer..... - in der Firma - werde ichnur Systemfresser drauf laufen lassen (Photoshop zb.)

 

Hallöchen

sag' mal bist Du inzwischen an dem - ja noch recht aktuellen - Problem weitergekommen?

Hier meine Situation:
Recht komplexe Access-Anwendung (sehr! viele, zum Teil nicht besonders performante Formulare) läuft auf Backend auf lokaler Festplatte mit für die Performance denkbar "ungünstigem" Datenbestand.
Eine bestimmte Abfrageserie (poste ich noch) braucht unter Windows 7 (E8400, 4GB, da fliegt die Kuh) etwa 1,5 Minuten *upps
Gleiche Abfrage auf XP in virtueller Maschine auf dem gleichen Rechner(!): Je nach Cachelage zwischen 4 und 7 Sekunden. *confused.gif*
Die Abfrage verändert dabei eine Cache-Tabelle im Frontend - dies liegt mittlerweile ordentlich in den Anwendungsdaten (dafür habe ich bei Vista-Einführung schon Lehrgeld bezahlt).
Ein Prozessorkern ist während der Abfrage voll ausgelastet, auf den Rechnern meiner Kunden kannst Du die Zahlen vervierfachen, da kommt bei Win 7 verständlicherweise nach 5 Minuten die Geierkralle zum Einsatz.

Beides in Access 2002 Runtime, exakt gleiche Version. Auf beiden läuft Avira ohne Heuristik, den Schirm zuzuklappen bringt keinen Unterschied.

Mir geht's dabei genau wie Dir - ich habe unzählige Programmierarbeit in die Performance der Abfragen gesteckt und bin endlich bei einem guten Niveau gelandet - dann kommt Win7 (ich bin ein tiefgläubiger Gates-Jünger und liebe Windows 7) und dann das. Die Anwendung umzukrempeln scheidet aus und es ist für mich ohne Frage ein Win7 Problem. Was können wir tun? Ich meine *WAS* können wir tun??? *smashing

Auf Ideen wie "XP-Mode verwenden" kann die Welt wohl verzichten - Dein Seitenhieb auf die Vorschläge zum Ausschalten der Rechtschreibprüfung und den kurzen Pfadnamen ist mir übrigens nach 10 Jahren Hardcore-Access-Entwicklung wie aus der Seele gesprochen *wink.gif*

 

Bitte mal zu Testzwecken den SearchIndexer an dem Client stoppen.
Dazu den entsprechenden Dienst "Windows Search" beenden.

 

Toll, vielen Dank für die schnelle Rekation! *top

Auch wenn mir vor Hoffnung ganz kribbelig wurde hat es leider nichts gebracht. *frown.gif* Allerdings lief die Anwendung noch, ich stelle den Dienst mal auf manuell und probiere es mit einem Neustart.

Ich vermute (ebenfalls?), dass es etwas damit zu tun hat, dass die Access-mde/mdb sich selbst ändert und irgendein "Festplattennutzungsintensiver" Dienst bzw. Prozess nicht damit klar kommt. Es muss ja was sein, was es unter XP/SP2 noch nicht gab, deshalb auch das gute Gefühl beim Search Dienst... Ich wühle mal ein wenig in den Ereignisberichten...

 

Neben dem Dienst laufen auch noch entsprechende Prozesse (SearchFilterHost.exe, SearchIndexer.exe, SearchProtocolHost.exe) zum Teil im Systemkontext.
Diese ggf. manuell beenden, sollten eigentlich beim beenden/stoppen des Dienstes automatisch runterfahren.

Ansonsten wie schon selbst festgestellt Dienst auf 'manuell' und neu starten.
Prüfen ob die obigen Prozesse laufen und nochmal testen.

Du kannst natürlich auch die entsprechenden Formate (*.mdb, *.mde, etc.) aus der Filterung rausnehmen... wäre dann möglicherweise eine Lösung des Problems, wenn es denn daran liegt...

 

Ja, das wäre Grund zur Freude wenn's denn daran liegen würde *rolleyes.gif*

Dienst ist deaktiviert, keiner der Indizierungs-Prozesse läuft, aber keine Änderung. Also gar keine.

Eine kosmetische Besonderheit fällt mir noch auf:

Unter XP erscheint der nutzlose "Abfrage wird ausgeführt" Fortschrittsbalken in der Statusleiste, bleibt für einige Zeit bei 0% oder 1% oder wie man den ersten "Kasten" interpretiert stehen und läuft dann zügig und linear durch bis auf 100%.
Unter Win7 bleibt der erste Kasten bis zum bitteren Ende stehen - Repaint-Ereignisse werden währenddessen nicht ausgeführt (was dann für meine Kunden in Verbindung mit wildem umherklicken umgangssprachlich als "der Computer hängt sich auf" interpretiert wird) - und dann ist er "plötzlich" fertig.

In der mde ist übrigens offensichtlich genug Luft zum arbeiten, die Dateigröße ändert sich während der Zugriffe nicht. Die Festplatte ist auch nur kurz aktiv, alles andere spielt sich in dem einen Prozessorkern ab - was auch immer das sein mag. (Gut, dass ich zwei hab', sonst könnte ich jetzt garnicht tippen *wink.gif* )
In %temp% ist ebenfalls nichts los... damn wenn ich nur wüsste was mein PC gerade denkt... und denkt... und denkt...

Den Tipp mit dem Indizierungsdienst fand' ich schon brandheiss, ich grübele mal weiter....

 

Welcher Prozess nutzt den einen Prozessorkern voll aus? vermutlich ist das msaccess.exe, oder?
Kannst du über den "Resource Monitor" etwas feststellen, das die Bremse darstellen könnte? (z. B. über Disk I/O oder Speicherzugriff usw.)

Um die Problemquelle noch mehr einzuschränken: das Problem tritt auch auf, wenn die Abfrage und die Tabellen in der gleichen mdb liegen, oder?

mfg
Josef

 

Ich kam auf den SearchIndexer, da dieser bei uns in der Firma kürzlich ein massives Performanceproblem bei grösseren MHT-Dateien (5-7MB) verursachte.
Aufbau der Dateien war extrem langsam auf Vista-Rechnern (die den SearchIndexer verwenden).
Die selben Dateien konnte in einer vergleichbaren Umgebung bzgl. Netzwerk, Rechnerausstattung, etc. mit WindowsXP deutlich schneller geöffnet werden.

Die Analyse ging anfangs auch Richtung Netzwerk, Platten, Rechte, etc.
Irgendwann kam mir dann in den Sinn dass es evtl. am Indexer lag... was sich bewahrheitete... Schade dass es hier nicht geklappt hat.

ProcMon sollte über die angesprochenen "Nadelöhre" Aufschluss geben.
Mühsame, aber manchmal unumgängliche, Kleinarbeit... *frown.gif*

 

Wir machen uns wohl gerade fast dieselben Gedanken...

...während Du geantwortet hast war ich im Safe-Mode. Es alles ist sooo schön schnell dort, nur nicht die Access-Anwendung. Die zeigt dasselbe Verhalten, die msaccess.exe ist das einzige was während den anderthalb Minuten CPU-Leistung beansprucht - 100% (bzw. 50%).

Der Ressourcenmonitor bestätigt das erstmal mit einem Oberflächlichen Blick: Quasi keine Datenträgeraktivität während der ganzen Zeit.

Vielleicht ist das einfach Bill's Art mir zu sagen: "8 Jahre zwischen OS und Anwendungssoftware? Das geht nun wirklich nicht"...

 

Glaub ich nicht, dass Bill das sagen will... wobei Microsoft - Official Home Page

Zurück zum Thema: Hol Dir bei MS mal den Processmonitor und lass den mitlaufen.
Nicht wundern, dadurch wird das ganze noch zäher werden als bisher, aber dafür bekommst Du ausführlichst mit, was wirklich passiert.

OT: Bin gerade dabei Monkey Island I wieder mal durchzuspielen... zum x-ten Mal *wink.gif*

 

Ja, die Probleme treten in praktisch allen Frontend-Backend-Szenarios gleichermassen auf. Es ist auch wurscht wo das Backend liegt. Was ich bei der Abfrageserie nämlich mache ist einen Indizierten und geordneten Zwischenspeicher mit Sammelinformationen im Frontend mit den im Backend geänderten Daten zu aktualisieren - okay, lass mich ehrlich sein - neu zu erstellen. Das ist zwar geknaupt, aber bei den geringen Datenmengen von denen hier die Rede ist auch wirklich (noch) tragbar. Nur eben nicht unter Windows 7. Dazu als Faktor ungünstige Datentopologie bei genau dieser Kundin und schwupps - 2 bis 5 Minuten für eine "Speichern und Schliessen" Aktion. So lässt sich ja objektiv nicht arbeiten.

 

9 year old milk... *Wegschrei* - muss ich mir für meine nächste DAU-Schulung aufschreiben.