Office: (Office 2010) Performance-Problem "Berechnung läuft..."

Guten Morgen,

ich habe eine Datenbank-Anwendung (FE/BE), die in einem zentralen Formular die Kunden eines Jahres anzeigt, die dann dort bearbeitet bzw. ergänzt werden können.

In der Tabelle sind insgesamt ca. 7.000 Datensätze, pro Jahr sind es aber
nur ca. 450

Trotzdem haben wir seit ein paar Wochen das Phänomen, dass in der Statusleiste des Formulars angezeigt wird "Berechnung läuft..." und auch
die Performance "gefühlt" in den Keller geht.

Kennt jemand dieses Phänomen? Was kann ich da tun?

Über Tipps würde ich mich freuen!

Vielen Dank und schöne Grüße
Anja

:)

 

Ohne nähere Informationen: Vielleicht hift Hand auflegen.

Ansonsten:
- Was hat sich geändert?
- Welche Steuerelemente beziehen Daten aus Tabellen, Abfragen, Berechnungen, Domänenaggregatfunktionen?
- Welche relevanten Indizes gibt es, und wie werden diese genutzt?
- Wie lautet der Pfad des Backends? Was ist das überhaupt für ein Backend?
- Gibt es eine ständige Verbindung zum Backend?
- Das Netzwerk ist leistungsfähig?

 

Hallo
alles was Eberhard Schreibt !
und seine Fragen beantworten !

im weiteren kannst Du in meiner Doc s. Fusszeile unten rechts
ab Seite 60
5.2 Performance Verbesserung
das ganze Kapitel 5.2 bis Seite 68 Lesen
besonders wichtig Permanente Verknüpfung mit der Daten–MDB zur Performance Verbesserung
das fragt ja Eberhard auch schon

im weiteren Seite 63
Im Zusamenhang mit Performance ist auch sehr Wichtig Kurze Pfad-namen und nicht Zuviel zu Tief verschachtelt

 

Hallo,

erstmal Dank für Eure Infos.

Entscheidend ist ... es hat sich in den letzten Monaten nichts verändert außer
der Anzahl der Datensätze...

Aber ich werde erstmal Eure Links nutzen und etwas lesen. Falls ich gar nicht weiterkomme, melde ich mich wieder...

Besten Dank und sonnige Grüße
Anja

 

Hallo
nur noch zwei Sachen zum schnell ausprobieren :
• Disk von FE und BE Defragmentieren
• Virenscaner Zum Testen Ausschalte
Es ist sinnvoll, die Dateien vom Typ ".LDB"(LACCDB) von der Virensuche auszunehmen (sofern der zuständige SysAdmin
überzeugt werden kann).

fragen:
ist das BE überhaupt im Netz ?
und ist das FE Lokal auf einem Disc ?
ist das FE eine ACCDB oder ACCDE oder sogar ACCDR

 

ich vermute mal, da ist das FE mächtig auseinandergegangen.
Jede Abfrage erzeugt temporäre Daten im FE, entweder das FE komprimieren oder wenn das nichts hilft, die FE-Objekte in ein neues leeres FE importieren und das BE wieder einbinden.

 

Änderung der Datensatzanzahl heißt in etwa in Zahlen?

 

Hallo zusammen,

hier noch ein paar Infos:
- Änderung der DS-Zahl heißt, dass pro Jahr etwa 900-1.000 Datensätze dazukommen
- Im Formular werden aber nur die DS eines Jahres angezeigt, nicht alle
- FE wird beim Schließen immer automatisch komprimiert
- FE und BE liegen physikalisch auf dem selben Server
- Pfad-Länge LW:\Ordner1\Ordner2 (also Tiefe 2)
- FE / BE sind ACCDB

Gruß,
Anja

 

Hallo Anja!

Und alle Anwender verwenden dieses eine FE?

Wolfgang

 

Hallo

das FE gehört immer bei jedem User Lokal auf den Disc wo hoffendlich auch das MSACCESS.EXE ist
und das FE sollte mindestens ein MDE sein
und so erstelle ich mit access2003 meine FE's
Erstellen der (FE-) MDE
MDE ist schon etwas besser als MDB
Vor dem erstellen der MDE bei der MDB
• Extra/Analyse/Leistung über Alle objekte / Alle auswählen und laufen lassen evtl. korrekturen vohrnehmen
• automatische Komprimieren ausschalten
• dann die MDB Decompilieren s. Donkarl 1.23 www.donkarl.com?FAQ1.23
• danach wieder Compileren und Reparieren – Komprimieren
• je nach dem könnte man hier auch RebuildDatabase von Thomas Möller anwenden
(Willkommen bei Team-Moeller.de - TM-RebuildDatabase)
• evtl. mit JETCOMP.exe Reparieren – Komprimieren JETCOMP kann man von MS runterladen.
• und jetzt erst die MDE erstellen. (Extra Datenbank Dienstprogramme MDE erstellen)
• Das FE gehört lokal auf den PC des User’s, dadurch gibt es weniger Netzwerkverkehr,
weil nur die Daten übers Netz gehen müssen. *Smilie

 

Hallo,

klingt ja alles spannend und hoch interessant!

Bei unserem Kunden ist die Situation so, dass an allen Arbeitsplätzen (ca. 10) ThinClients stehen und die Nutzer auf dem Server arbeiten.

Außerdem setzen wir aufgrund der Arbeitsanforderungen sehr umfangreich die Einbindung von Word-Serienbriefen ein. Das hat nach meiner Erfahrung zur Folge, dass ich keine MDE (o.ä.) einsetzen kann, sondern die offene Datenbankanwendung (wobei natürlich Entwursfmodus ausgeblendet und vor dem Nutzer verborgen wird) verwenden muss.

Gibt es einen bestimmten Grund, warum die autmatische Komprimierung nicht verwendet werden soll? War mir bisher nicht so bewusst...


Vielen Dank und beste Grüße
Anja

 

Ich für meinen Teil habe in meinem Berufsleben viele solcher Datenbanken betreut und hatte zuweilen die gleichen Probleme.
Als DB-Admin war es mir immer wichtig, für alle möglichen Queries (Abfragen) passende Indizes auf die Tabellen zu legen. Dies unterstützt auf jeden Fall den DB-Optimizer, der ja, wie bei allen relationalen Systemen, die Zugriffe verwaltet.
Beachten Sie auch, dass Queries wie (.... WHERE NAME LIKE *XYZ*") bei wachsendem Volumen immer länger laufen werden, da bei jedem Aufruf ein TableScan durchgeführt wird, weil Indizes (hier auf Feld NAME) keine Verwendung finden können. Bei bestimmten Joins führt u.U. auch eine fehlerhafte Verknüpfung zu immensen Laufzeiten. Ich habe schon gesehen, dass sich Anwender ein sog. Karthesisches Produkt erzeugt hatten und dieses dann per DISTINCT bereinigt wurde. Sehr unglücklich, wenn man von Normalisierung keine Ahnung hat.

Weiterhin ist es bei zunehmendem Datenvolumen auf jeden Fall auch notwendig, die BackEnd-DB zu komprimieren. Das wird zuweilen problematisch werden, wenn mehrere/viele Anwender gleichzeitig die Anwendung benutzen. Hierfür sollten Sie also einen passenden Zeitpunkt wählen.

Weiterhin viel Erfolg und Gruß - Dieter



Noch eine kleine Anmerkung: Selbstverständlich kann jeder Anwender seinen FrontEnd auf dem eigenen PC komprimieren, so oft er will. Das stört niemanden. Weiterhin ist es ein Trugschluss zu glauben, dass nur die Daten über das Netzwerk geleitet werden, die per Query angefordert werden.
Wird eine Abfrage im FrontEnd ausgeführt, kommt selbstverständlich erst einmal das ganze Volumen durch die Leitung und wird im BackEnd aufbereitet.
Bei nicht komprimiertem BackEnd wird das von Tag zu Tag länger dauern.
Um nur Ergebnisse über die Leitung zu schicken, müssen Sie mit Stored Procedures arbeiten. MS-Access wird Ihnen bei Anwendung durch viele Mitarbeiter aber nicht sehr dankbar sein. Besser und zu empfehlen wäre hier ein SQL-Server, ist aber eine Geldfrage.

 

Das in Zusammenhang halte ich für fragwürdig bis Unsinn.

VBA-Code ist nach dem ersten Durchlauf spätestens auch compiliert, so wie bei der MDE (da findet es bei der MDE-Erstellung statt.) Prägnante Laufzeitunterschiede entstehen dann auch nicht durch VBA, außer man macht einiges deutlich anders.

Welche Berechnungen laufen denn nun? Meine Fragen oben wurden sehr unvollständig beantwortet.

 

"Berechnung läuft..." ist eine der nichtssagenden Bemerkungen von Microsoft,
ähnlich etwa wie "Ein unerwarteter Fehler ist aufgetreten".

 

Hallo
wenn Du es nicht mit einer
ACCDE oder sogar ACCDR versuchen willst
dann musst Du ja auch nicht auf automatische Komprimierung verzichten
wobei das bei access vor 2010 manchmal zu Fehler führte