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

Hallo!

Ja, genau das meinte ich.

Ich bin mir allerdings nicht sicher, ob das dann auch bei ADODB-Connections hilft.
Ich würde in diesem Fall auch nur eine ADODB-Connection zum BE öffnen und diese geöffnet lassen, um sie für die ADODB-Recordsets usw. zu verwenden.


Allg. Tipp zur Problemsuche:
Verwende nicht das komplexe Frondend sondern erstelle dir eine oder mehrere Testanwendungen mit sehr einfachen Formularen bzw. Datenzugriffen um die Problemursache zu finden.
Loggen der Daenzugriffe im Code kann auch helfen, um die Codeabschnitte bzw. Vorgänge zu finden, die die Zeit beanspruchen.

mfg
Josef

 

Hallo
ist Dein FE eine ACCDB oder ACCDE
wenn nicht ACCDE
wieso nicht ?
schon versucht sie als Runtime zu starten (ACCDR)(mde) startet als Runtime ?

 

\@Alfred:
Das war nur ein Beispiel für einen ganz einfachen Fall, beidem es schon Schwierigkeiten gibt.
Ungebunde Felder? Nun, die dienen doch ledioglich der Eingabe von Filterwerten.
Und nochmals: Wenn ich allen mit der DB arbeite ist das kein Problem, daher kann diese simple Abfrage über diese paar Werte nicht das Problem sein. Die Ursache muss wonaders stecken.

@josef:
Wie funktioniert das mit dem Loggen, ich muss gestehen, das hab ich noch nie gemacht. Vielleicht kan ich da ja wirklich was heraus bekommen.
So extrem habe ich das auch noch nie erlebt mit der Performance. *frown.gif*
Ich arbeite in der DB komplett mit ADO

@Rudolf:
Das BE ist ne ADODB , das FE ist ne ADODE.
Alle User außer mir arbeiten mit ner Access Runtime Version, haben also kein "richtiges" Access.
Kann hier das Problem liegen?

Ich überlege ja das Backend auf SQL-Server zu verlagern, macht aber nur Sinn, wenn ich die Probleme dann nicht mit verlagere. Zumindest hätte diese Verlagerung bie Nutzung von Views auf dem Server order bei Path Through Abfragen, dass die Rechenlast auf dem Server liegt und die Daten nicht über unser Netzwerk müssen. Wir haben zwar ein Gigabit Netz aber keine Ahnung, was unsere IT-Security da so treibt. Hab bei einer anderen Sache mit bekommen, dass sie bei JEDEM Schreibvorgang in eine SharePoint Tabelle nen Virenscanner starten. 5 Datensätze = 5 Schreibvorgänge *mad.gif*

 

Hallo!

Wenn du komplett mit ADO arbeitest, wie greifst du auf die Daten zu?
Verwendest du CurrentProject.Connection als ADODB-Connection oder erstellst du direkt eine Connection auf das Backend?
Bei letzterem sollte das LDB-Locking-Problem nur beim ersten Öffnen der Connection auftreten - und das ist dann vernachlässigbar.


Bezüglich Umstellung auf SQL-Server: Das bringt auf jeden Fall etwas - wenn du die Anwendung in diese Richtung optimierst. Das ist aber keine 1-Tages-Aktion. ;-)
Ob Sicht oder Pass-Through-Abfrage kommt auf die Verwendung an. Auch bei als Tabelle verknüpfte Sichten kann Jet die Filterbedinungen über ODBC an den SQL-Server weiterreichen, wenn diese nicht so formuliert sind, dass sie nur Jet versteht (Grundregel: indexfreundliche Bedinungen schreiben - aber das sollte man bei Jet ebenso machen).
Gerade beim SQL-Server würde ich bei OLEDB mit ADODB bleiben und dann machen PT-Abfragen eigentlich nur noch bei Berichten Sinn. Für komplexere Vorgänge starte ich beispielsweise per ADODB-Connection eine gespeicherte Prozedur am Server und lass den arbeiten.

mfg
Josef

 

Hallo Josef,

ich verwende CurrentProject.Connection.

Was die Umstellung betrifft, habe ich das ganze schon mal bei einer anderen DB unter 2003 durchgezogen, daher ist mir das mit den SP nicht unbekannt.
Damals hatt ich aus der DB ein Projekt gemacht aber die DB hatte eh mehr oder weniger nur Anzeigefunktionen und Eingaben dienten nur der Filterung.
Grund war damals aber WAN und die schlechte Performance die dadurch veruersacht wurde.
Mein aktuelles Problem tritt ja in einem Gigabit-Netz auf, da alle am selben Standort sitzen.
Zurück zur Umstellung, da machen ja besonders WENN und TRUE/FALSE Spaß und noch einige andere Geschichten die ich unter Access in VBA umgesetzt habe. Da zickt SQL Server ja gerne mal rum. *frown.gif*

 

Mir ist gerade noch aufgefallen, dass es, selbst wenn ich ein geöffnetes Formular in nur die Entwurfsansicht versetze, schon extrem lange dauert.

Nach meinem Verständnis werden da doch gar keine Daten bearbeitet.

 

Mir ist gerade noch was eingefallen.
Aus der Entwurfsphase habe ich auf ein paar Feldern der Haupttabelle noch Nachschlagefunktionen, könnten die für des Performanceproblem verantwortlich sein?
Eigendlich dürften die doch bei Abfragen nicht stören, oder?

 

Hallo

Sprichst Du diese Felder in der Abfrage an ?
wenn Ja könnte das schon etwas bremsen.

Hast Du
in den Tabelleneigenschaften Unterdatenblattname auf „keines“
gesetzt ?
lade dir von Thomas Möller
Willkommen bei Team-Moeller.de - TM-TablePerformance
runter das setzt auch auf „keines“

und Hast Du in den Tabelleneigenschaften Sortiernach etwas gesetzt ?
denn lösche das und versuche ob es etwas hilft

 

Hallo,

ich muss mich wieder mal zu diesem Thema melden.
Versuchsweise habe ich mal den langen UNC-Pfad des Backends auf B:\ gemappt.
Der Name der Backend-DB ist aber noch länger als 8 + 3, wobei +3 ja mit der aktuellen ACESS-Version eh nicht mehr passt (accde).
Das Backend konnte ich aktuell noch nicht umbenennen, da mit der DB gearbeitet wird.
Das Mappen hat absolut keine Preformance-Gewinne gebracht.
Allein das Umschalten des Hauptformulars in den Entwicklungsstatus dauert 70 (!!!) Sekunden. Und das Hauptformular hat keine Datensatzquelle, da es nur Buttons zum Öffnen anderer Formulare enthält.

Ich mag nicht so recht glauben, das das mit der Länge des Pfades zum BE bzw. mit der Länge des Namens der BE-Tabelle zu tun hat.
Ach, diese extremen Laufzeiten treten auch nur dann auf, wenn mehrere Kollegen via lokaler FEs auf dieses BE zugreifen.
Der Unmut über dieses Laufzeitverhalten wirde verständlicher weise immer größer.

Gibt es noch andere Ideen zu diesem Problem?

Gruß

cheapy

 

Hallo,
ich habe jetzt nicht alles hier durchgelesen.

Aber ich hatte jetzt schon 2 mal Probleme dass (vermutlich) nach einem Accessupdate nach Bearbeitung des FE der Zugriff auf das BE extem lange dauerte.
Abhilfe schaffte hierbei ein Komprimieren des FE/BE mit der gleichen Access-"version".

 

Zumindest das FE ist so eingestellt, dass es sich beim schließen komprimiert.

Mit dem BE werde ich es bei nächster Gelegenheit mal probieren.
Aber das erklärt für mich nicht diese extrem lange Zeit die gebraucht wird um eine simples Formular in den Entwicklungsmodus umzustellen.

 

Hallo,

Mach doch mal eine Kopie deines FE und deines BE.und komrimieres dieses BE
Teste in dieser Konstellation.
Hilft das nicht lösche alle Tabellen im FE (der Formularentwurf sollte trotzdem aufgehen).
Hilft das auch nicht, baue das FE mal neu auf.

BtW:
Die Objektautokorrektur hast du deaktiviert !?

 

Ich habe vorhin eine neue DB erstellt und ACCESS versucht gerade alles aus dem "alten" FE zu importieren. Dauert schon mehr als 30 Minuten und die ganze Geschichte hängt jetzt schon ewig bei &Beziehungen unter dem Reiter Module.

 

Hallo

Achtung wenn mehrere User gleich zeitig Auf das BE zugreifen ?
dann könnte Komprimieren zu Probleme führen.
dazu fortere ich alle User auf zu schlissen
und Komprimiere das BE (NICHT automatisch !)

ich Komprimiere Nie Automatisch ! Auch nicht Das FE

das FE ist ein ACCDE ? schon versucht mit ACCDR ?

wenn du das FE nach folgenden Schema erstellt sollte alles OK sein

aus meiner Doc :

 

Hallo Rudolf,

das BE werde ich nachher komprimieren, wenn die Kollegen Feierabend haben.
Die Objektanalyse habe ich auch schon mehrfach laufen lassen.
Das FE hat jeder User lokal.
Die DB ist eine accde und die Kollegen arbeiten "nur" mit einer lokal installierten Access Runtime-Version.

Gruß

cheapy