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

Hallo zusammen,

bin etwas in Arbeit ertrunken, daher erst jetzt weitere Rückmeldungen.

Deine vielen Fragen - Eberhard - kann ich gar nicht so gut beantworten ;-)

Zunächst bekommt das Formular per Select-Anweisung die Datensätze eines Jahres. Mit den Indizies in den Tabellen war ich eher zurückhaltend, d.h. der Primärschlüssel ist indiziert. Vermutlich wäre es schlau, einen Index auf das Jahr einzurichten ;-)

Allerdings werden aufgrund des komplexen Arbeitsprozesses mehrere UF mit
Daten aus anderen Tabellen passend zum angezeigten Datensatz dargestellt.

Wie Indizes genutzt werden, weiß ich nicht. Ich dachte, ich trage in der Tabelle ein, welches Feld indiziert wird, den Rest macht die Engine von selbst ...

Die Tabellen sind per Verknüpfung eingebunden, damit vermutlich ständig verfügbar. Gibt es da noch andere Wege?

Leistungsfähigkeit des Netzwerkes ist hier nicht massgebend. Es arbeitet i.allg. auf diesem FE auch nur eine MA.

Welche Berechnung da angeblich läuft, kann ich nicht sagen. Ich weiß gar nicht, wie ich soetwas herausbekommen könnte ...

Das FE liegt C:\abc\apps\app1 und das BE liegt auf dem gleichen Server im Ordner C:\abc\daten

Derzeit probiere ich nach etwas doch irritierenden Rückmeldungen:
- Virenscanner ausschalten
- komprimieren beim schließen bleibt an
- regelmäßig das BE komprimieren (muss ich wohl "nachts" von hand machen?!)
- Gezielt einige weitere Indizes in den Tabellen im BE eintragen.


Herzlichen Dank für Euren Input!!!

Anja

 

...und ich arbeite gerade Abschnitt 5.2 von Rudolf durch ;-)

 

Wiederholung: Welche Steuerelemente beziehen Daten aus Tabellen, Abfragen, Berechnungen, Domänenaggregatfunktionen? Zu den Steuerelementen eines Formulares gehören auch Unterformulare und deren Steuerelemente ... alles mögliche saugt sich ja irgendwie Daten. Ein kleines unscheinbares Kombinationsfeld kann eine größere Abfrage bewegen als ein großflächiges Formular.

Daher: Falls gezielte Überlegungen nicht möglich sind, entferne in einer Kopie des Formulars nach und nach Steuerelemente und vergleiche das Verhalten.

Diesen Glauben teilen mit Dir viele, er entspricht aber nicht der Realität.
Siehe SQL ist leicht (8) - Index
Die verlinkte Anlage gehört mit zum Text.

 

Guten Morgen,

setze gerade diverse Vorschläge um und schaue, ob etwas passiert.

Dabei habe ich gelesen, dass intern Long schneller als Int verarbeitet wird.
Hat das auch für Access 2010 und ff. noch Bestand?

Besten Dank

Anja

 

Wo und in welchem Zusammenhang hast Du das gelesen?

Die Herleitung, dass 4 Byte schneller verarbeitet werden als 2 Byte, wäre doch interessant.

 

...auf dem Verweis "SQL ist leicht (8) ..." steht am Ende ein Verweis auf ein Dokument "Index und Indexnutzung".

Da drin steht auf S. 15 im Abschnitt "Long-Schlüssel für Join":

Der Datentyp Long Integer wird von allen Datentypen am schnellsten verarbeitet.



Gruß,
Anja

 

Dort darf man aber davon ausgehen, dass kleinere Zahlen-Datentypen nicht zu "allen" Datentypen hinzuzurechnen wären, sondern schlicht aus der Betrachtung ausgelassen wurden, weil deren Wertebereiche für Schlüssel dann auch für Datenbanken mit ihren Datenmengen schlicht unzureichend sind:
Integer: Bereich von -32.768 bis 32.767
Byte: Bereich von 0 bis 255