Geschwindigkeitsverlust im Mehrbenutzer-Betrieb

[bahasu]

Hallo,

wenn in der in frontend (auf jedem PC vorhanden) und backend (auf dem Server vorhanden) aufgeteilten multiuser-Datenbank ein zweiter Benutzer arbeitet (d.h. Daten anschauen bzw. bearbeiten), komme ich nur sehr langsam in den Entwurf-Modus von Formularen, Berichten, Abfragen, VBA und das Speichern dauert länger als eine Minute.

Keine Geschwindigkeitseinbussen habe ich, wenn mehrere Benutzer ,,nur" die Daten via Formular bearbeiten, d.h. keinerlei Entwicklungsarbeiten durchgeführt werden.

Auch die üblichen Hinweise (z.B. in http://www.granite.ab.ca/access/performancefaq.htm)
- persistenten Recordset aufbauen,
- Subdatasheet Name property set to [None],
- kurze Dateinamen
bringen keine Verbesserung bei der Geschwindigkeit.

Was kann ich machen, um Formularen auf meinem PC schneller bearbeiten zu können, auch wenn ein zweiter Benutzer aktiv ist?

Harald


PS a2003 und a2007 sind im Einsatz

[Beaker s.a.]

Hallo Harald,

Was kann ich machen, um Formularen auf meinem PC schneller bearbeiten zu können, auch wenn ein zweiter Benutzer aktiv ist?

Während der Entwicklung die Verbindung zum
Backend kappen, oder mit einer lokalen Kopie
arbeiten.
hth
gruss ekkehard

[bahasu]

Während der Entwicklung die Verbindung zum
Backend kappen, oder mit einer lokalen Kopie arbeiten.

Hi Ekkehard,

und wenn ich dann die Verbindung wieder herstellen will, dann kann ich dort ca. 10-15 Minuten darauf warten, bis die Tabellen neu verknüpft sind. 

Bei einer anderen Datenbank, die zum Teil mit denselben backend-Daten und mit einer vergleichbaren Struktur arbeitet, gibt es keine Wartezeit bei der Formularentwicklung. Mein Vergleich bei Extras>Optionen hat keine Unterschiede gezeigt zwischen der db mit und der ohne Wartezeiten.

Bin also weiterhin für Tipps dankbar, die mir sagen, wo ich das "Häckchen an der richtigen" Stelle setzen muss. 

Harald

[Beaker s.a.]

Hallo Harald,

und wenn ich dann die Verbindung wieder herstellen will, dann kann ich dort ca. 10-15 Minuten darauf warten, bis die Tabellen neu verknüpft sind

Das müssen dann aber eine Menge sein, wenn das
so lange dauert. Ich arbeite gerade an einer DB, die
ich zwischen Büro und zu Hause transportiere, also
auch jedesmal neu verknüpfen muss. Die hat z.Zt.
ca. 50 verknüpften Tabellen (sogar in mehreren BEs),
und das geht eigentlich unmerklich beim Start von statten.
Zum Problem fällt mir dann allerdings auch nichts mehr
ein.
gruss ekkehard

[bahasu]

Hi Ekkehard,

danke für Deinen Hinweis.

Die "endlose" Verknüpfungsdauer tritt nur dann auf, wenn ein anderer Benutzer bereits in der db ist.
Wenn ich alleine drin bin, geht das Neuverknüpfen (beim Wechsel zwischen den Daten im Büro und denen, die ich zu Hause zum Weiterbasteln habe bzw Server-Daten und Testdaten) schnell genug.

Also weitersuchen...

Harald

[database]

Hallo,

Die "endlose" Verknüpfungsdauer tritt nur dann auf, wenn ein anderer Benutzer bereits in der db ist

Was aber dann auch bedeutet, dass deine Tabellen, dein Backend von unterschiedlichen Frontends bedient werden.

Was mir in dem Zusammenhang Anlaß zur Kritik gibt. Wechselst du denn die Frontends nach einer Weiterentwicklung nicht generell aus?

[bahasu]

Was aber dann auch bedeutet, dass deine Tabellen, dein Backend von unterschiedlichen Frontends bedient werden.

Was mir in dem Zusammenhang Anlaß zur Kritik gibt. Wechselst du denn die Frontends nach einer Weiterentwicklung nicht generell aus?

Hi Peter,

auf dem Server ist neben dem Backend auch ein Frontend vorhanden.
Dieses Frontend wird bei einem Aufruf der Datenbank automatisch durch eine Kopieraktion auf den PC des Benutzers gebracht. Der Benutzer arbeitet dann mit dem kopierten Frontend auf seinem PC.

Der Hinweis "unterschiedliche Frontends" trifft allerdings so lange zu, so lange ich die in Bearbeitung befindliche Frontend-Version noch auf meinem PC habe und noch nicht auf den Server für die oben angesprochene Kopieraktion zur Verfügung gestellt habe.

Dieses Vorgehen wende ich bei unterschiedlichen Datenbanken an.
Nur bei einer Datenbank habe ich die angesprochenen Geschwindigkeitseinbußen, sofern ich z.B. ein Formular bearbeite und ein anderer Benutzer auf das Backend zugreift. Dies tritt nur an der Arbeitsstätte und nicht an der privaten PC-Umgebung auf. Wenn ich zu Hause gleichzeitig von unterschiedlichen Rechnern über das private Netzwerk zugreife, so ist die Arbeitsgeschwindigkeit bei der Formularbearbeitung ok.

Harald

[database]

Hallo Harald,

Dieses Frontend wird bei einem Aufruf der Datenbank automatisch  ...

Genau das ist der richtige Vorgang, habe auch vermutet dass das so gemacht wird - ist halt so leider nicht ganz zu erkennen gewesen, daher mein Einwand.

Der von dir weiter angesprochene Geschwindigkeitsverlust ist in einer Netzwerkumgebung mit mehreren Faktoren verbunden.
Da du schreibst, dass dieser Effekt nur bei einer DB auftritt liegt der Schluß nahe, dass diese gegenüber den anderen eine oder mehrere Besonderheiten aufweist.
Neben der Netzbelastung / Auslastung spielt auch die Gestaltung der Tabellen ebenso eine Rolle wie deren Anzahl (die an der Datenherkunft des Formulars beteiligt sind).
Auch ob das Formular nur durch Tabellen oder aber von einer komplexen Abfrage 'gespeist' wird.
Sind in dem Formular Berechnungen vorhanden kann dies ebenfalls zu derartigem Verhalten führen, Unterformulare in Verschachtelungen, Dlookups auf Tabellen die nicht durch
normalisierte Beziehung an die Datenherkunft gebunden sind, DLookups allgemein sowie 'langatmige' Prozeduren fördern die Performance einer DB im Netzwerk nicht gerade.

Auch die Verbindung auf ein nicht optimal gestaltetes Datenmodell des BE kann massive Geschwinigkeitseinbußen nach sich ziehen.
Dass es im privaten Netzwerk 'normal' verläuft läßt sich auch darauf zurückführen, dass ein privates Netzwerk in keiner Weise dem Traffic eines Unternehmenesnetzwerks unterliegt.

Sind denn die BE der gut funktionierenden DBs in der gleichen Verzeichnisstruktur wie das problematische gespeichert?
Gibt es unterschiedliche Berechtigungsstrukturen bei den Speicherorten?
Liegen die BE auf dem gleichen Server?
So sind eine Vielzahl von Einflüssen für die Performance einer DB verantwortlich.

[bahasu]

Hi Peter,

danke für Deine Anregungen.

Die Lösung ist, dass ich die persistente Verbindung nicht nur zu dem einen backend, sondern auch zu dem zweiten aufbauen muß.
Habe also gelernt, dass es zu persistent auch noch die Steigerungform "persistenter" gibt.

Jetzt ist die Formular-Bearbeitungsgeschwindigkeit wieder ok.

Harald