Office: (Office 2010) Zugriff auf Backend Tabellen sehr langsam

Hallo,

ich habe eine Datenbank erstellt, die von mehreren Kollegen genutzt wird.
Diese habe ich in Front- und Backend aufgeteilt, um den bekannten Problemen aus dem Weg zu gehen und ein paralleles Arbeiten zu ermöglichen.
Das Backend befindet sich auf einem Netzlaufewrk.

Nun habe ich das Problem, dass die Datenzugriffe (Dlookup, Tabelle öffnen, Execute SQL) auf die verknüpften Tabellen sehr langsam sehr langsam sind.
Das Öffnen der Tabellen und das Ausführen von SQL-Befehlen mache ich mit ADODB-Zugriffen.
Es geht hier vorrangig um lesende Zugriffe auf die Tabellen des Backends.
Das Problem scheint beim öffnen der jeweiligen Tabellen zu liegen, da die zu lesende Datenmenge immer sehr gering ist. Oft werden weniger als 10 Datensätze gelesen.
Ich habe einen Tipp gefunden demzufolge ich eine verknüpfte Dummy-Datei vom Backend immer geöffnet lassen soll.
Aber eine wirkliche Verbesserung hat das nicht gebracht.
Ansonsten hane ich beim Googeln nichts wirklich aufschlussreiches gefunden.

Hat jemand eine Idee, wie ich das verbessern kann?

gruß

cheapy

:)

 

Warum verknüpfst Du die Tabellen aus dem BackEnd nicht "einfach" ins FrontEnd
Dann kannst Du sie ohne große Anstrengungen wie lokale Tabellen behandeln.
Auch die SQL Befehle kannst Du dann gegen currentdb feuern.

 

Sollte ich mich missverständlich ausgedrückt haben?
Die Tabellen sind ja ins Frontend verknüpft.

Allerdings sind sie nicht über einen Laufwerksbuchstaben Plus Pfad sondern über eine UNC-Pfadangabe verknüpft.
Das musste ich leider machen, da die Kollegen ihre Netzlaufwerke nicht alle gleich verbunden haben.
UNC ist das ja an der Stelle egal.

 

Wie "tief" ist die Ordnerstruktur zum BackEnd?
Ich musste kürzlich erst selbst feststellen, dass das einen zum Teil erheblichen Einfluss auf die Performance beim Zugriff hat...

Hat jeder User sein eigenes, lokales FrontEnd?

Wieso wird per ADODB zugegriffen, wenn Du ein Access-BackEnd verwendest?

 

Der UNC-Pfad besteht aus 8 Ebenen.

Wie greife ich denn per VBA sonst auf Access-Tabellen zu?
Ich habe mal gelesen das ADO neuer als DAO ist, daher habe ich das genommen.

 

ADO hat AFAIK nur Vorteile, wenn Du z.B. auf einen SQL zugreifst.
DAO ist für reine JET-Datenbanken (Access) nach meiner Erfahrung die bessere Variante.

Kannst Du testen wie es sich verhält, wenn Du das BackEnd ins Root-Verzeichnis des Laufwerks legst ?

 

Ich hatte vorher die Daten lokal, da ging es deutlich besser.
So wie es sich mir dartsellt, ist das Öffnen der Tabellen das Problem.
Zumindest hängt es dort beim debuggen recht lange.

 

Ich meine kein lokales Laufwerk sondern die oberste Ebene des verbundenen Netzlaufwerks... das es lokal schneller geht ist nachvollziehbar und logisch.

Ist der Zugriff auf das BackEnd nur langsam wenn per VBA (ADO !?) zugegriffen wird, oder auch wenn Du die Tabelle direkt aufrufst oder als Datenherkunft eines Formulars verwendest?

 

Hast Du das Backend schon komprimiert?

 

Wie lang sind die einzelnen Verzeichnisnamen und der Dateiname?
Möglichst nicht länger als nach der 8.3 Konvention.

 

Hallo!

Eventuell auch das ldb-Locking (z. B. durch geöffnetes RS während die Anwendung läuft) minimieren.
Ich bin mir jetzt allerdings nicht sicher, ob es sinnvoll ist, alle möglichen und sinnvollen Optimierungsmaßnahmen aufzuzählen.
@cheaptrick: du bist ja kein Access-Neuling mehr *Smilie und ich gehe davon aus, dass du im Frontend die meisten Maßnahmen schon eingebaut hast.

Unter http://access.joposol.com/accept/anw...indigkeit.html gibt es ein paar Links zum Thema "Geschwindigkeit".

Interessehalber:
Spielt der lange Pfad auch dann eine Rolle, wenn bereits eine ADODB.Connection oder ein DAO.Database-Instanz direkt zum BE geöffnet ist und diese verwendet wird?

[OT]
DAO vs. ADODB: Seit Access 2007 ist DAO wieder neuer als ADODB. *wink.gif*
Trotzdem verwende ich gerne ADODB, wenn ich auf aktive DBMS (vor allem MSSQL) zugreife.
Für den Zugriff auf Access-Tabellen verwende ich (und das tat ich auch als ADODB von MS beworben wurde *biggrin.gif*) hauptsächlich DAO, da diese Bibliothek gut auf Jet/ACE abgestimmt ist.

Einen Vorteil hat für mich ADODB neben der etwas schnelleren und für mich einfacheren Zugriffsart auf aktive DBMS: ich kann bei Recordsets die Verbindung kappen und senke damit die Last am DB-Server.
(Das könnte eventuell auch für Jet/ACE-Backends interessant sein, falls das Netzwerk nicht sehr stabil ist. - Erfahrung hab ich damit allerdings nicht, da ich kein Access-BE mehr einsetze.

mfg
Josef

 

Puh, das waren bis hier hin ja schon mal viele Tipps.
Was den Hinweis der Speicherung in der Root-Ebene betrifft: Da darf ich nichts speichern. Nicht das das technisch nicht gehen würde aber es gibt hier so einige für mich nachvollziehbare Restriktionen. Hängt u.a. mit Daten- bzw. Zugriffsschutz zusammen.
Was die Verzeichnisnamen betrifft, si sind die nicht übermäßig lang, teilweise nur 2 Zeichen. Nur Root ist da deutlich länger.
Zum Thema ADO / DAO, mir schwebt weiterhin im Kopf das Backend in absehbarer Zeit zu verwerfen und die Daten auf einer SQL-Server-DB abzulegen.
Daher werde ich bai ADO bleiben, so wie ich das verstanden habe, ist das ja dann auch besser.
Da sind allerdings auch erst wieder organisatorische Dinge zu klären, als kann das noch ein weilchen dauern.
Ich komprimiere die DB regelmäßig, habe aber noch nicht auf accde umgestellt.

Performance-Verbesserungen habe ich im Zusammenhang mit SQL-Server ja dadurch erreicht dass ich ein Access-Projekt aufgesetzt habe. Nun habe ich allerdings gelesen, dass es dieses in Access 2013 nicht mehr geben wird. Hier ist zwar ein Wechsel vorerst nicht geplant aber ich will mir da keine zusätzlichen Schwierigkeiten aufbauen.

 

Nach meinen Erfahrungen gibt es keine gravierenden Performanceunterschiede bei der Verwendung von DAO oder ADO.
Zwischen mapping und UNC-Pfad habe ich auch noch nie Unterschiede festgestellt.

Da Du das Backend auf einem Server hast, müsste erst einmal festgestellt werden, ob der Flaschenhals die Anwendung ist oder das Netzwerk. Ich würde dazu einmal Frontend und Backend auf dem Rechner ablegen und die Geschwindigkeit testen.
Wenn es dann immer noch zu langsam ist, würde ich einzelne Abfragen, Formulare testen.
Als nächstes ein neues Frontend anlegen und die Objekte aus dem aktuellen Frontend importieren. Ggf. ist das Frontend defekt.

 

Vielleicht hilft eine direkte Freigabe: Als nicht \\Server\Freigabe\OrdnerEbene1\OrdnerEbene2\...\OrdnerEbene8\Backend.mdb, sondern direkt den Ordner freigeben, in dem das Backend liegt: \\Server\Freigabe\Backend.mdb Das würde den UNC-Pfad verkürzen, ohne die physische Ordnerstruktur zu ändern.

Zum Testen ggf. auch den Backend-Dateinamen wie oben gesagt in 8.3 Namenskonvention ändern, wenn das nicht schon so ist.

 

Hallo
evtl. helfen dir folgende Punkte aus meiner Doc s. Fusszeile unten rechts
evtl alle Tip’s aus 5.2 …. jedoch zuerst
Seite 60
5.2.1.1 Tabelle Optimieren

seite 61
5.2.1.2 Permanente Verknüpfung mit der Daten–MDB zur Performance Verbesserung
5.2.2.1 DBEngine(0)(0) / CurrentDBC

Seite 63
Kurze Pad und Datei Namen
MDB /MDE als Runtime Starten

? wie ist es mit deinem Vierenscaner ?
evtl. einmal zum Testen ausschalten *wink.gif*
auf jeden fall ".LDB" ausschliesen vom Test