Office: (Office 2010) Datenbank extrem langsam

Hallo die Runde,

meine DBank die ich in der letzten Zeit zusammen mit Euch gebastellt hat, wurde heute ins Netz eingebunden und ist sogar beim nur einem User-Zugriff extrem langsam.
Ich habe schon einiges im Forum gelesen und umgestellt.
Client freigegeben, ausgelagert, BE im Netz, FE local.

Was könnte ich noch machen?
Unser Netz ist ziemlich schnell, z.B. CAD Catia-Zugriff auf Modell von ca. 100 MB 2 b. 5 sec. Speichern ung. das Gleiche.

IT-Mann sagte, Access ist Sch.. und ist keine Lösung und lacht mich aus.

Was könnte der Grund dafür sein?

FE hat 2,7MB, BE 13MB und 80 Einträge

Bitte um Unterstützung

Grüsse

taki

:)

 

Sind die Modelle in Files abgelegt oder werden sie über einen DB-Server zur Verfügung gestellt?

Wenn du ein Access-BE nutzt, ist die Geschwindigkeit des File-Server-Zugriffs wichtig, der aber meistens schnell genug sein wird.

... weil er vermutlich von Access keine Ahnung hat und nur das allgemeine Bla-Bla nachquatscht. *biggrin.gif*

Wie schnell ist die Anwendung, wenn du das BE in einem lokalen Verzeichnis verwendest?
Wenn es dort auch so langsam ist, würde ich auf fehlende Tabellenoptimierung tippen.

Aber:

Wenn das bereits Probleme macht, muss mehr schief laufen als nur fehlende Indizes, denn 80 Einträge müssten auch bei einem Table-Scan ruck-zuck angezeigt werden. *Smilie
Vielleicht ist ein besonders fleißiger Virenscanner im Einsatz.

mfg
Josef

 

Hallo
schon wieder einen verweis auf meine Doc, wie bei Deinen zwei letzten Problemen.
hier http://cid-0838611f737bd3d9.office.l...unterlagen.pdf

ca. Seite 57
5.2 Performance Verbesserung
das ganze Kapitel 5.2 .........

 

Hallo Josef,
danke für Deine schnelle Reaktion.
Also unsere CAD Modell sind in Files abgelegt und freigegeben, keine DB.
Meine DB, FE+BE local auf meinem Laptop läuft's sehr schnell.
Vom Netzwerk sehr langsam, von 3 sec. local auf 3 Minuten im netzwerk.
Virenscanner wurde abgehängt, keine Besserung.

Grüsse taki

 

Wie passt das zusammen?

3 sec. local: Für 80 Einträge müsste eine sehr ungünstige Gestaltung verwendet werden, um so langsam zu sein.
Wenn ich mir diese Gestaltung anschaue (Acc2007 - Access-Formulare): Das ist zwar funktional, aber mitnichten performant. Und da die Datenübertragungsrate bei einem Netzwerk deutlich niedriger ist als auf einer lokalen Festplatte, werden ungünstige Gestaltungen deutlicher offengelegt.

Grundlagenlektüre: Performance in Abfragen von Michael Zimmermann

 

Hallo Eberhardt,

in jedem Eintrag sind etliche Speicheintensive Daten abgelegt, wie z.B. ein Foto (120x150px), Lebenslauf im Original, Zeugnisse und anderes gescanntes Zeug.

Ich sehe, n. Rüdi Hinweis, dass ich etliche Sachen anders gestallten muss. Momentan müssen wir lokal arbeiten.

Was meint Ihr, wird der Bericht über Abfrage schneller?

Danke und viele Grüsse

Tadeus

 

Speicherintensive Daten würde man nicht automatisch mitladen, sondern erst dann, wenn sie wirklich benötigt werden (Einzelaufruf?). Wenn es dann lange dauert, ist es ein Netzwerk- und nicht ein Access-Problem (Grüße zurück an den Experten).

Die Frage verstehe ich nicht. Abfragen (SQL-Anweisungen) stellen Daten aus Tabellen zusammen und werden vielfachst verwendet. Es kommt aber nicht nur darauf an, dass man Abfragen verwendet, sondern sehr stark darauf, wie die Abfragen gestaltet sind.

 

Ich hab zwar Rüdi´s Dokument nicht gelesen, aber sowas würde ich doch grundsätzlich verlinken... Pfad speichern und über diese Verknüpfung die Dokumente öffnen.

 

Speicherst du diese Daten direkt in der Tabelle (in Anlagefeldern) ab?
Falls ja: wie viele Daten erwartest du für das Backend?
Mehr als 2 GB Dateigröße ist nämlich nicht möglich.

Zum Überlegen wäre, ob man diese Bilder statt in der DB nur im Fileserver speichert und in der DB nur den Link zur Datei ablegt - oder falls ein Sharepoint-Server verfügbar ist, diesen dafür nutzt - sollte ein Sharepoint 2010 verfügbar sein, könntest du sogar überlegen, ob du eine Access-Web-Anwendung nutzt.

mfg
Josef

 

Hallo
@josef er hat gesagt
BE 13MB und 80 Einträge
das sind ca. 0.16 MB pro Eintrag

@tadeus
ich denke das bei diesem verhältnise ein Link auf die Bilder und Bilder seperad als bmp oder jpg speichern möglicherweise etwas bringen könnte.

 

Hallo Josef,

nach dem ich alle CV's und anderes Zeug gelöscht habe, ist die BE auf ca. 3MB abgespeckt. Es hat aber nix, gar nix der Zugr.Geschwindigket geholfen.
Es ist Sch.. hoch zwei.
Aber, die Hunde bellen usw.

Gruesse

Tadeus

 

Läuft denn da irgendwelcher Code beim Formular öffnen oder Datensatzwechsel ab?

 

Was ist eigentlich so langsam?
Ist es der Datenzugriff? ... wobei ich mir das nicht vorstellen kann, dass ein Zugriff auf nur 80 Datensätze so extrem langsam ist.

Die typischen Sachen wie Objektnamenautokorrektur, dauerhaft geöffnete Verbindung vom FE zum BE u. ä. hast du schon korrigiert, oder?

Falls der Datenzugriff so langsam ist, dann schau dir einmal den Jet-Showplan an, ob in der Abfrage Indizes genutzt werden können. (Was allerdings bei nur 80 DS egal sein sollte.)

Stöbere auch einmal ein wenig in Over 100 Tips for Faster Microsoft Access Databases.
Anm.: Optimierungen, die sich aber nur im Millisekundenbereich auswirken, kannst du dir für später aufheben.

mfg
Josef

 

Hallo
möchte noch nach hacken
das was ich in meiner Doc unter
5.2 Performance Verbesserung
geschrieben habe hast Du alles gemach ?
Tabellen Optimierung,
Permanente Verknüpfung,
Indexe nach Michael Zimmermann (AEK)
Kurze Pfad/Datei Namen (nicht länger als 8 Zeichen)
Objekname-Autokorrektur alles ausgeschaltet
CurrentDB ersetzt mi DBEngine(0)(0) oder CurrentDBC
Feld vom Typ Text, Memo oder Hyperlink Unioncode auf Ja
im VBA-Code Resourcen Frigaben

Dateien (FE/BE) Decompiliert / Repariert u. Komprimiert

und , und ...............


Noch was es gibt aus der Schweiz Neu Hochgeschwindikeits PC's
die haben nur 15 Sec. um Windows XP hoch zufahren
das währe doch was für Euch *boah *depressed *dance *wink.gif*

 

Hallo Experten,

danke für Ihre Tipps, momentan arbeitet DB lokal.
Es sieht so aus, dass ich die ganze Struktur nach Rüdi seinem Hinweisen umstellen muss. Momentan keine Zeit dafür. Wahrscheinlich erst am WE. Unser IT denkt auch mit und probiert auch ein paar Sachen aus.

Gruesse
Tadeus