backend-frontend im netz zu langsam

[Bojic Milan]

hallo ng

ich habe eine db für planungsverwaltung im architekturbüro erstellt. mein
problem ist daß diese db, wenn sie geteilt wird, viel zu langsam öffnet(20-
30sec oder länger abhängig von benutzerzahl). dabei ist backend im netzwerk
und frontend lokal und nie mehr als 5 nutzer zugleich. ungeteilte datenbank
auf demselben laufwerk im netz ist viel schneller bzw. es gibt kein
unterschied ob 2 oder 5 nutzer gleichzeitig zugreifen.
nach der ms beschreibung müsste die geteilte wariante schneller und
stabiler sein

[Felix Bahrenburg]

Hallo Bojic,

"Bojic Milan" schrieb

Post by Bojic Milan
ich habe eine db für planungsverwaltung im architekturbüro erstellt. mein
problem ist daß diese db, wenn sie geteilt wird, viel zu langsam öffnet(20-
30sec oder länger abhängig von benutzerzahl). dabei ist backend im netzwerk
und frontend lokal und nie mehr als 5 nutzer zugleich. ungeteilte datenbank
auf demselben laufwerk im netz ist viel schneller bzw. es gibt kein
unterschied ob 2 oder 5 nutzer gleichzeitig zugreifen.
nach der ms beschreibung müsste die geteilte wariante schneller und
stabiler sein

Du solltest Dir im klaren darüber sein das ACCESS (JetEngine) nicht extra ür
den
Client/Server(sprich FE/BE) konzipiert ist. Auch ist es nicht damit getan
die
ACCESS Tabellen in eine .MDB auf dem Netzwerkserver zu platzieren und dann
die Tabellen in den FEŽs zu verknüpfen. Ganz besonders nicht wenn es eine
Mehrbenutzerumgebung ist.

Wir können Dir hier natürlich einige Ratschläge geben um Dein Problem zu
lösen, ich neige aber
dazu in solchen Fällen die MSDE zu empfehlen. Dann hast Du die Leistung
eines SQL-Servers
und bezahlst dafür keinen müden Cent. Die Installation ist in 5Minuten
erledigt und das "importieren" der Tabellen klappt zu 95%
mit nur wenigen Mausklicks. Lass es Dir mal durch den Kopf gehen ;-))

http://www.microsoft.com/germany/sql/2000/technologien/msde/default.mspx
http://www.microsoft.com/downloads/details.aspx?FamilyID=413744d1-a0bc-479f-bafa-e4b278eb9147&displaylang=de

Gruß
Felix

[Reiner Wolff]

Moin Felix,

Du produzierst Kammquotes. Stelle doch bitte einmal Deinen Newsreader
richtig ein[1] oder benutze einen vernünftigen Newsreader[2], danke.

Post by Felix Bahrenburg
"Bojic Milan" schrieb

Post by Bojic Milan
ich habe eine db für planungsverwaltung im architekturbüro erstellt. mein
problem ist daß diese db, wenn sie geteilt wird, viel zu langsam öffnet(20-
30sec oder länger abhängig von benutzerzahl). dabei ist backend im netzwerk
und frontend lokal und nie mehr als 5 nutzer zugleich. ungeteilte datenbank
auf demselben laufwerk im netz ist viel schneller bzw. es gibt kein
unterschied ob 2 oder 5 nutzer gleichzeitig zugreifen.

Du solltest Dir im klaren darüber sein das ACCESS (JetEngine) nicht extra ür
den
Client/Server(sprich FE/BE) konzipiert ist. Auch ist es nicht damit getan
die
ACCESS Tabellen in eine .MDB auf dem Netzwerkserver zu platzieren und dann
die Tabellen in den FE´s zu verknüpfen. Ganz besonders nicht wenn es eine
Mehrbenutzerumgebung ist.
Wir können Dir hier natürlich einige Ratschläge geben um Dein Problem zu
lösen, ich neige aber
dazu in solchen Fällen die MSDE zu empfehlen. Dann hast Du die Leistung
eines SQL-Servers
und bezahlst dafür keinen müden Cent. Die Installation ist in 5Minuten
erledigt und das "importieren" der Tabellen klappt zu 95%
mit nur wenigen Mausklicks. Lass es Dir mal durch den Kopf gehen ;-))

An dieser Stelle sollte man erwähnen, dass der Umstieg auf den SQL-Server:
1. bei weitem nicht schneller als Access sein muss (kommt auf die
Implementierungen an)
2. komplett andere Datentypenbezeichnungen bzw. Datentypen benutzt,
die nicht einfach richtig übernommen werden (und das soll nur in 5%
der Fälle der Fall sein?)
3. die MSDE als SQL-Server auch eine Administration braucht, wenn mal
etwas ist.
4. das Problem von Bojic vielleicht überhaupt gar nicht löst
5. durch den Workload-Manager der MSDE dafür gesorgt werden könnte,
dass das ganze bei 5 gleichzeitigen Benutzern, die über eine
Access-Anwendung darauf zugreifen, richtig langsam werden kann,
da die MSDE normaler Weise nur 8 gleichzeitige Zugriffe normal schnell
bearbeitet und Access gerne über mehrere gleichzeitige Connections
pro Client arbeitet.

Und Bojic ...
6. dann die Datenbankstruktur, die Formulare und der VBA-Code auf
den SQL-Server optimiert werden sollten und nicht für die Jet-Engine.
Optimiert sollten die Teile aber auf jeden Fall werden, da es sonst
wenig bringt.
7. ... sich vermutlich noch überhaupt nicht mit dem SQL-Server auskennt
und sich da dann einarbeiten sollte.

Ich will diese Dinge nur zu bedenken geben, denn strukturelle Probleme
lösen sich nicht von selbst durch die Benutzung eines SQL-Servers, im
Gegenteil sie bleiben bestehen.
Ansonsten steige auch ich gerne bei mehr als 5 Usern wenn möglich gerne mal
auf den SQL-Server um.

@Bojic:
Wenn das FrontEnd sich so langsam öffnet, dann ist vermutlich mindestens
einer der folgenden Punkte erfüllt:
- das Startformular ist nicht ungebunden oder
- ein AutoStart-Makro sorgt für die Ausführung von (für den Netzbetrieb)
"unsauber" programmiertem Code
- das Netzwerk ist unheimlich lahm :-)

Das ist nur ein kleiner Einstieg, um dem Problem etwas auf die Schliche zu
kommen. Andere hier könnten Dir das sicherlich besser und prägnanter
aufzeigen, allerdings könnte man dazu etwas genauere Informationen zum
Startablauf bei Dir gut gebrauchen ;-)

HTH
Greetinx aus Kiel
Reiner

Fußnote(n):
===========
[1] www.oe-faq.de
[2] Programm: http://www.40tude.com/dialog/
Anleitung: http://www.gaehn.org/software/40tude-dialog/tutorial/

[Felix Bahrenburg]

Post by Reiner Wolff
Moin Felix,
Du produzierst Kammquotes. Stelle doch bitte einmal Deinen Newsreader
richtig ein[1] oder benutze einen vernünftigen Newsreader[2], danke.

Danke für den Hinweis und auch für die Links, benutze keine manuellen
Zeilenumbrüche mehr.
Da ich erst seit kurzem durchs Usenet geistere, ist das zwar keine
Entschuldigung, aber hoffentlich ein Grund für Dich mir zu vergeben ;-)

Post by Reiner Wolff
1. bei weitem nicht schneller als Access sein muss (kommt auf die
Implementierungen an)
2. komplett andere Datentypenbezeichnungen bzw. Datentypen benutzt,
die nicht einfach richtig übernommen werden (und das soll nur in 5%
der Fälle der Fall sein?)
3. die MSDE als SQL-Server auch eine Administration braucht, wenn mal
etwas ist.
4. das Problem von Bojic vielleicht überhaupt gar nicht löst
5. durch den Workload-Manager der MSDE dafür gesorgt werden könnte,
dass das ganze bei 5 gleichzeitigen Benutzern, die über eine
Access-Anwendung darauf zugreifen, richtig langsam werden kann,
da die MSDE normaler Weise nur 8 gleichzeitige Zugriffe normal schnell
bearbeitet und Access gerne über mehrere gleichzeitige Connections
pro Client arbeitet.

Mit dieser Argumentation hättste mich fast selbst überzeugt, d.h. Deine
Argumente sind ja im Endeffekt alle schlüssig, sprich richtig.
Auch ich konnte und kann noch immer nicht einschätzen über welche (Grund-)
Kenntnisse Bojic verfügt. Nur manchmal ist die Schwellenangst zum Umstieg
auf SQL-Server (hier explizit MSDE) nur oft größer als Sie sein müsste.
Daher gebe ich auch vielen Studenten und Studentinnen den Rat sich einmal
damit zu beschäftigen. Nicht zuletzt weil ich darauf hoffe das sie sich dann
auch mal eingehender mit der Relationalität in DBMS beschäftigen. Das
BojicŽs Problem mit einer Anpassung der Tabellen, oder "nur" an
verschiedenen ACCESS-Einstellungen liegt, ist SEHR wahrscheinlich.

Post by Reiner Wolff
Ich will diese Dinge nur zu bedenken geben, denn strukturelle Probleme
lösen sich nicht von selbst durch die Benutzung eines SQL-Servers, im
Gegenteil sie bleiben bestehen.

Liegt auf der Hand *g*

War auf einem Missionars-Trip, man sagt mir auch nach das ich nur mit
handauflegen, Ungläubige zum Glauben führe kann ;-))

Gruß aus Heiligendorf/Wolfsburg
Felix

[Michel Fouquet]

Hallo,

Post by Felix Bahrenburg
Daher gebe ich auch vielen Studenten und Studentinnen den Rat sich

auf keinen Fall Deine Rechtschreibung, Zeichensetzung und Grammatik
anzueignen.

Post by Felix Bahrenburg
Liegt auf der Hand *g*

joo, wie man am folgenden Satz leicht nachvollziehen kann.

Post by Felix Bahrenburg
War auf einem Missionars-Trip, man sagt mir auch nach das ich nur mit
handauflegen, Ungläubige zum Glauben führe kann ;-))

;-)

Michel

[Felix Bahrenburg]

*rööölpzzz*

Wir können auch gerne rausgehen und das Problem dort "weiterdiskutieren"

;-))

[Reiner Wolff]

Moin Felix,

Post by Felix Bahrenburg

Post by Reiner Wolff
Du produzierst Kammquotes. Stelle doch bitte einmal Deinen Newsreader
richtig ein[1] oder benutze einen vernünftigen Newsreader[2], danke.

Danke für den Hinweis und auch für die Links, benutze keine manuellen
Zeilenumbrüche mehr.
Da ich erst seit kurzem durchs Usenet geistere, ist das zwar keine
Entschuldigung, aber hoffentlich ein Grund für Dich mir zu vergeben ;-)

Es gibt nichts zu vergeben. :-)
Ich freue mich, wenn sich jemand dieser gut gemeinten Ratschläge annimmt.
Das ist bei weitem nicht immer der Fall.
Wenn Du erst kurz dabei bist, dann hast Du vielleicht auch Interesse an
weiteren Hinweisen (zB sollte die Einleitungszeile nicht über zwei Zeilen
gehen) und Links wie
http://einklich.net/usenet/rules.htm
oder speziell für diese NG
http://www.doerbandt.de/access/Newbie.htm

Post by Felix Bahrenburg

Post by Reiner Wolff
1. bei weitem nicht schneller als Access sein muss (kommt auf die
Implementierungen an)
2. komplett andere Datentypenbezeichnungen bzw. Datentypen benutzt,
die nicht einfach richtig übernommen werden (und das soll nur in 5%
der Fälle der Fall sein?)
3. die MSDE als SQL-Server auch eine Administration braucht, wenn mal
etwas ist.
4. das Problem von Bojic vielleicht überhaupt gar nicht löst
5. durch den Workload-Manager der MSDE dafür gesorgt werden könnte,
dass das ganze bei 5 gleichzeitigen Benutzern, die über eine
Access-Anwendung darauf zugreifen, richtig langsam werden kann,
da die MSDE normaler Weise nur 8 gleichzeitige Zugriffe normal schnell
bearbeitet und Access gerne über mehrere gleichzeitige Connections
pro Client arbeitet.

Mit dieser Argumentation hättste mich fast selbst überzeugt, d.h. Deine
Argumente sind ja im Endeffekt alle schlüssig, sprich richtig.

*g*
Ich will ja auch gar nicht von der MSDE abraten, aber es ist halt kein
Allheilmittel ;-)

Post by Felix Bahrenburg
Daher gebe ich auch vielen Studenten und Studentinnen den Rat sich einmal
damit zu beschäftigen. Nicht zuletzt weil ich darauf hoffe das sie sich dann
auch mal eingehender mit der Relationalität in DBMS beschäftigen.

Hm, fromme Hoffnung.
Es gibt einfach Begriffe (referentielle Integrität, Primärschlüssel,
Normalform), mit dem man etwas anfangen können sollte, wenn man mit
Datenbanken umgehen können will. Und das ist imho völlig unabhängig vom
benutzten Datenbanksystem.

Greetinx aus Kiel
Reiner

[Henry Habermacher [MVP Access]]

Hallo Felix

Post by Felix Bahrenburg
Du solltest Dir im klaren darüber sein das ACCESS (JetEngine) nicht
extra ür den
Client/Server(sprich FE/BE) konzipiert ist. Auch ist es nicht damit
getan die
ACCESS Tabellen in eine .MDB auf dem Netzwerkserver zu platzieren und
dann die Tabellen in den FE´s zu verknüpfen. Ganz besonders nicht
wenn es eine Mehrbenutzerumgebung ist.

Was schreibst Du da blos für einen Unsinn! Genau das ist der richtige
Ansatz. Lies' mal das Papier Betrieb von Access Anwendungen, das es beim
www.debdev.org zum Download gibt.

Henry

[Felix Bahrenburg]

GuMo Henry,

Post by Henry Habermacher [MVP Access]

Post by Felix Bahrenburg
Du solltest Dir im klaren darüber sein das ACCESS (JetEngine) nicht
extra ür den
Client/Server(sprich FE/BE) konzipiert ist.

Um das gleich vorwegzunehmen : Man KANN ACCESS/Jet NATÜRLICH als
Client/Server Lösung einsetzen. Für viele Anwendungen ist Jet in Sachen
Performance und Datenintegrität absolut ausreichend und was anderes wäre
sogar "zuviel des Guten". Aber möchtest Du mir jetzt weis machen das Du für
eine Mehrbenutzerumgebung, sagen wir "nur" 30 Benutzer haben gleichzeitig
Zugriff, Du ACCESS als BE einsetzen würdest?? Das würdest Du mit Sicherheit
nicht tuen.

Bojic hier den Rat zu geben sich die MSDE anzuschauen war sicher etwas
verfrüht, ohne sein Problem näher zu kennen, allerdings wenn er schon weiß
das es da was anderes als ACCESS gibt, das auch noch "kostenlos" ist (bei
entsprechenden Voraussetzungen) dann weiß er das und kanns im Hinterkopf
behalten.

Post by Henry Habermacher [MVP Access]

Post by Felix Bahrenburg
Auch ist es nicht damit
getan die
ACCESS Tabellen in eine .MDB auf dem Netzwerkserver zu platzieren und
dann die Tabellen in den FEŽs zu verknüpfen. Ganz besonders nicht
wenn es eine Mehrbenutzerumgebung ist.

Was schreibst Du da blos für einen Unsinn! Genau das ist der richtige
Ansatz.

Ein richtiger Ansatz, ja, aber damit ist es allein nicht getan. Das weißt Du
selbst sicher besser als ich das tue.

Post by Henry Habermacher [MVP Access]
Lies' mal das Papier Betrieb von Access Anwendungen, das es beim
www.debdev.org zum Download gibt.
Henry

Danke, werde ich tuen.

Gruß
Felix ;-)

*AnIntressierteEin"E"verkaufe* *fg*

[Henry Habermacher [MVP Access]]

Hallo Felix

Post by Felix Bahrenburg
GuMo Henry,

Post by Henry Habermacher [MVP Access]

Post by Felix Bahrenburg
Du solltest Dir im klaren darüber sein das ACCESS (JetEngine) nicht
extra ür den
Client/Server(sprich FE/BE) konzipiert ist.

Um das gleich vorwegzunehmen : Man KANN ACCESS/Jet NATÜRLICH als
Client/Server Lösung einsetzen. Für viele Anwendungen ist Jet in
Sachen Performance und Datenintegrität absolut ausreichend und was
anderes wäre sogar "zuviel des Guten". Aber möchtest Du mir jetzt
weis machen das Du für eine Mehrbenutzerumgebung, sagen wir "nur" 30
Benutzer haben gleichzeitig Zugriff, Du ACCESS als BE einsetzen
würdest?? Das würdest Du mit Sicherheit nicht tuen.

Access erlaubt maximal 255 gleichzeitige Benutzer. Bis 50 Benutzer ohne
komplexe Zugriffe ist eine Jet als BE durchaus tauglich, mit 30 Benutzern
nicht überfordert. Hängt doch einzig und alleine davon ab, was damit gemacht
werden soll. Wenn es um eine einfache Adressverwaltung und
Serienbrief-Erzeugung geht, dann läuft das mit ausreichender Performance und
Stabilität auch mit 50 Benutzern und ist kein Grund auf eine MSDE zu
wechseln, welche einiges mehr an KnowHow erfordert, als eine Jet Engine.

Post by Felix Bahrenburg
Bojic hier den Rat zu geben sich die MSDE anzuschauen war sicher etwas
verfrüht, ohne sein Problem näher zu kennen, allerdings wenn er schon
weiß das es da was anderes als ACCESS gibt, das auch noch "kostenlos"
ist (bei entsprechenden Voraussetzungen) dann weiß er das und kanns
im Hinterkopf behalten.

Da würde ich eher den Tipp geben, den SQL Server 2005 Express und das SQL
Server Management Studio 2005 Express anzuschauen, welche es zur Zeit gratis
bei MS gibt. Da ist wenigstens ein vernünftiges Verwaltungswerkzeug dabei,
eine MSDE ohne Enterprise Manager zu verwalten ist für
Otto-Normalverbraucher ziemlich schwierig.

Post by Felix Bahrenburg

Post by Henry Habermacher [MVP Access]

Post by Felix Bahrenburg
Auch ist es nicht damit
getan die
ACCESS Tabellen in eine .MDB auf dem Netzwerkserver zu platzieren
und dann die Tabellen in den FE´s zu verknüpfen. Ganz besonders
nicht wenn es eine Mehrbenutzerumgebung ist.

Was schreibst Du da blos für einen Unsinn! Genau das ist der richtige
Ansatz.

Ein richtiger Ansatz, ja, aber damit ist es allein nicht getan. Das
weißt Du selbst sicher besser als ich das tue.

Ich arbeite genut mit Access und SQL Server um zu wissen, was wo gemacht
werden kann, das hast Du richtig interpretiert, aber wenn jemand schreibt
"das ACCESS (JetEngine) nicht extra für den Client/Server (sprich FE/BE)
konzipiert" sei, dann ist das IMNSHO schlicht und einfach Unfug/Unsinn und
verwirrt nur die Benutzer. Die Jet Engine ist speziell für den Mehrbenutzer
bereich ausgelegt und war sie von Anbegin an, sonst hätte diese wohl kaum
für Werkzeuge wie den Exchange Server herhalten können, welche ein
intensives Mehrbenutzer Umfeld darstellen und würde auch nicht über eine
integrierte Benutzerverwaltung und Locking Mechanismen verfügen, welche in
einem Nicht-Mehrbenutzerumfeld nur die Performance negativ beeinflussen.

Gruss
Henry

[Felix Bahrenburg]

Um das gleich vorwegzunehmen : >>...

...

Auch ist es nicht damit getan >>>> ...

...
Habe den Mund sehr voll genommen, nach 2 Jahren ACCESS/DAO/VBA/.../ habe ich
"kaum" Erfahrung! Das ist so, es kommt auch nicht so von heute auf Morgen.
Wenns so wäre, wärŽ ich "MVP" ;-)) Žwerde mich zukünftig etwas
zurückhalten, zumindest nicht so vorschnelle "Antworten" auf Fragen geben.
*g* Denn, davon gehe ich Mal aus, kann ich in diesen NGs noch einiges
lernen.

MfG
Felix

[Michael Zimmermann]

Hallo!

mein problem ist ...

... daß Deine Shift-Taste kaputt ist?

... daß diese db, wenn sie geteilt wird, viel zu langsam
öffnet(20- 30sec oder länger abhängig von benutzerzahl).
dabei ist backend im netzwerk und frontend lokal und nie
mehr als 5 nutzer zugleich. ungeteilte datenbank auf
demselben laufwerk im netz ist viel schneller bzw. es
gibt kein unterschied ob 2 oder 5 nutzer gleichzeitig
zugreifen. nach der ms beschreibung müsste die geteilte
wariante schneller und stabiler sein

Im BE in allen Tabellen im Entwurf die Eigenschaft
'Unterdatenblatt' auf 'None' stellen.

Überall unter Extras/Optionen/Allgemein die
Objektnamen-Autokorrektuer vollständig ausschalten
(Alle drei Häkchen weg). Da vermutlich mit eingeschalteter
ONAK entwickelt wurde, alles nochmal in leere neue Mdbs
importieren, wo die ONAK von vornherein aus ist.

Beim DB-Start ein gebundenes Formular unsichtbar öffnen
oder ein Recordset auf irgendeine Tabelle des BE erstellen,
das permanent im Hintergrung geöffnet bleibt und erst beim
Beenden des FE wieder von Dir geschlossen wird.

Diese drei Grundregeln helfen in 90% der Fälle.

Ansonsten heißt es halt, gebundene Formulare auf Abfragen
statt auf Tabellen aufzusetzen und diese Abfragen auch
sinnvoll zu optimieren. Hierzu:

www.donkarl.com/AEK/AEKDownloads/AEK8_Abfragen_Performance.zip

Gruß aus Mainz
Michael

[Milan Bojic]

Hallo!

Herzlichen Dank für die Antworten. Meine Access und VB Kenntnisse sind in
der Tat eher gering und ein Umstieg auf MSSQL oder MySQL wäre mir eine
Nummer zu groß, es heisst nicht umsonst: "Schüster bleib bei..."
Die DB habe ich vor 3-4 Jahren begonnen, als ich selbst nicht wusste was es
so richtig werden soll, duch die Projekte immer wieder angepasst und
modifiziert ist sie inzwischen recht kompliziert, besonders der
Startformular bzw. die dazugehörige Abfrage. Viele Begriffe in Eueren Tips
höre ich zum ersten mal, werde mich ab sofort damit beschäftigen (soweit es
mir, zur Zeit viele, Wettbewerbe im Büro es zulassen).

Bitte die Rechtschreibung nicht zu streng beurteilen: ich ausländer,
anderes baustelle...

mfG
MB

[Bernd Möhle]

Hallo Bojic,

ich hatte auch Performance-Probleme zum Start eines Formulares bzw.
Berichtes. Schau Dir mal den Eintrag "Startverhalten FRM A2000" in dieser NG
an.

Hat mir auch geholfen....

Gruß, Bernd

Post by Bojic Milan
hallo ng
ich habe eine db für planungsverwaltung im architekturbüro erstellt. mein
problem ist daß diese db, wenn sie geteilt wird, viel zu langsam öffnet(20-
30sec oder länger abhängig von benutzerzahl). dabei ist backend im netzwerk
und frontend lokal und nie mehr als 5 nutzer zugleich. ungeteilte datenbank
auf demselben laufwerk im netz ist viel schneller bzw. es gibt kein
unterschied ob 2 oder 5 nutzer gleichzeitig zugreifen.
nach der ms beschreibung müsste die geteilte wariante schneller und
stabiler sein

[Henry Habermacher [MVP Access]]

Hallo Bojic

Post by Bojic Milan
ich habe eine db für planungsverwaltung im architekturbüro erstellt.
mein problem ist daß diese db, wenn sie geteilt wird, viel zu langsam
öffnet(20- 30sec oder länger abhängig von benutzerzahl). dabei ist
backend im netzwerk und frontend lokal und nie mehr als 5 nutzer
zugleich. ungeteilte datenbank auf demselben laufwerk im netz ist
viel schneller bzw. es gibt kein unterschied ob 2 oder 5 nutzer
gleichzeitig zugreifen.
nach der ms beschreibung müsste die geteilte wariante schneller und
stabiler sein

Dieses Verhalten kommt von einem Fehlverhalten von Access her, das jeweils
beim Aufbau einer Verbindung zur Backend versucht herauszufinden, ob es die
erste Connection ist. Falls nicht, kann es zu einem Timeout kommen
(lock-Timeout), bis Access weiss, dass es die LDB nicht löschen kann.

Dieses Verhalten kann man über einen permanenten Link in die Backend und ein
persistentes Recordset beheben, welches beim Öffnen der Anwendung anlegt.
Dann wird das einmal gemacht, danach ist Ruhe.

Ich habe dieses hier letzte Woche bereits beschrieben. Such' mal in
Groups.Google.de nach "Access persistentes Recordset", denke Du wirst fündig
werden. Ansonsten die Access Performance FAQ von Tony Toews (Link in der
deutschen FAQ), dort dann ebenfalls nach persistent Recordset Ausschau
halten. Danach wirst Du feststellen, dass es nur leicht langsammer läuft,
als mit einer lokalen MDB.

Es lohnt sich dabei vielleicht auch mal das Papier "Betrieb von Access
Anwendungen" zu lesen, welches es beim dbdev.org im Download Bereich gibt.
Auch die Vortragsunterlagen (PPT) von Karl Donaubauer anlässlich der letzten
AEK (www.donkarl.com) zum Starten von Access Anwendungen über Starter
Anwendungen lohnt sich in Deinem Fall sicher.

Gruss
Henry

[Anton Huber]

Bojic Milan <***@moserarchitekten.at> threw this exception:

Hallo!

Post by Bojic Milan
ich habe eine db für planungsverwaltung im architekturbüro erstellt. mein
problem ist daß diese db, wenn sie geteilt wird, viel zu langsam öffnet(20-
30sec oder länger abhängig von benutzerzahl). dabei ist backend im netzwerk
und frontend lokal und nie mehr als 5 nutzer zugleich. ungeteilte datenbank
auf demselben laufwerk im netz ist viel schneller bzw. es gibt kein
unterschied ob 2 oder 5 nutzer gleichzeitig zugreifen.
nach der ms beschreibung müsste die geteilte wariante schneller und
stabiler sein

Der Tipp mit dem ständig geöffnetem RS auf eine >Dummytabelle<
im BE ist ja schon gefallen.

Dazu ein kleiner Hinweis zu einem Verhalten von Acc2k:

Bei einem Projekt von mir habe ich ein Updateprogramm für die FEs
geschrieben. D.h. die Benutzer durften nicht mehr das FE direkt
öffnen sondern nur dieses Updt-Programm. Dieses Programm lädt
vom Fileserver das neue FE (falls vorhanden) herunter und öffnet
danach das FE.
In dem nacktem neuen FE werden dann zuerst die Tabellen vom BE
programmatisch eingebunden und das persistente RS geöffnet.

Alles cool ...

Nein doch nicht: Bei dieser Art passierte es sehr oft das entweder
plötzlich Sperren auf Datensätze lagen die überhaupt nie wer
geöffnet/angerührt hatte, aber auch das wiederum die
Geschwindigkeit drastisch langsam wurde.
Ich habe da Nächte lang daran gesessen, debugged und Kaffee
getrunken, so richtig verstehe ich es bis heute nicht. Es ist jedoch
in einem solchen Scenario wichtig das FE zweimal zu öffnen.
Beim ersten Öffnen werden die TabLinks erstellt beim zweiten
Öffnen nur mehr das persistente RS geöffnet. Nur so ist scheinbar
sichergestellt das Acc (kann nur von 2k sprechen) alles richtig
'versteht' ...


Gruss
Anton

[Peter Steimann]

Hallo Anton

Post by Anton Huber
Bei einem Projekt von mir habe ich ein Updateprogramm für die FEs
geschrieben. D.h. die Benutzer durften nicht mehr das FE direkt
öffnen sondern nur dieses Updt-Programm. Dieses Programm lädt
vom Fileserver das neue FE (falls vorhanden) herunter und öffnet
danach das FE.

Ehrlich gesagt, find ich das nicht gerade gut. Wenn Du die FE's lokal hältst
und beim Start eine Versionsprüfung machen würdest, würd mir das schon
wesentlich besser gefallen...

Zudem hat das sachnellere Oeffnen den Nachteil, dass in eienr
Mehrbenutzer-Umgebung das FE immer langsamer wird, auch wenn die App nur
minimiert geöffnet und weggelegt wird.

Abgesehen davon kan es auch sein, dass Deine Datensicherung schlapp macht,
wenn noch eine Connection zum BE offen ist. User lässt den PC nachts
laufen-Du machst die Sicherung-Tags darauf verhauts den BE und Deine Daten
sind futsch!

[Anton Huber]

"Peter Steimann" threw this exception:

Hello Peter!

Post by Peter Steimann

Post by Anton Huber
Bei einem Projekt von mir habe ich ein Updateprogramm für die FEs
geschrieben. D.h. die Benutzer durften nicht mehr das FE direkt
öffnen sondern nur dieses Updt-Programm. Dieses Programm lädt
vom Fileserver das neue FE (falls vorhanden) herunter und öffnet
danach das FE.

Ehrlich gesagt, find ich das nicht gerade gut. Wenn Du die FE's lokal hältst
und beim Start eine Versionsprüfung machen würdest, würd mir das schon
wesentlich besser gefallen...

Ich denke da geht was quer ... ???

FEs liegen auf den Clients. Das Programm welches vorab (am Client)
gestartet wird überprüft ob eine neue Version am Fileserver liegt. Ist
dem so wird das 'neue' FE auf den Client geladen, wenn nicht wird
einfach das 'alte' FE auf dem Client gestartet.
Dieser Vorgang hat mal mit Access prinzipiell gar nichts zu tun ...
In diesem Fall ist es nicht nur ein FE. Es sind auch zusätzlich
diverse dlls und anderes Zeugs ...

Post by Peter Steimann
Zudem hat das sachnellere Oeffnen den Nachteil, dass in eienr
Mehrbenutzer-Umgebung das FE immer langsamer wird, auch wenn die App nur
minimiert geöffnet und weggelegt wird.

Verstehe nicht ganz? Da wird nichts minimiert geöffnet?!?

Also nochmal:
Updater wird gestartet -> kein neues FE da. O.k. altes FE am Client
wird gestartet.

Nächter Tag: Updater wird gestartet -> neues FE da. O.k. FE
vom Server wird auf den Client geladen. Neues FE wird (lokal)
gestartet. FE bindet Tabellen vom BE ein. FE schliesst sich nach
dieser Aktion automatisch. Updater sartet mit kurzer Verzögerung
das FE (lokal) nochmals und schliesst sich danach selber.

Wie gesagt dies ist die einzige Möglichkeit gewesen >>keine<<
Geschwindigkeitsverluste zu erhalten. Da der Zielpfad des
BEs variabel ist und die Tabellen erst beim Start eingebunden
werden. In allen anderen Fällen wurde es unerträglich langsam
bzw. es lagen auch Sperren auf DSes die nie 'berührt' wurden
(Soll heissen gleich am Anfang).

Dieses System läuft nun bereits 2 1/2 Jahre mit etwa 30 Clients
sehr stabil.

Post by Peter Steimann
Abgesehen davon kan es auch sein, dass Deine Datensicherung schlapp macht,
wenn noch eine Connection zum BE offen ist. User lässt den PC nachts
laufen-Du machst die Sicherung-Tags darauf verhauts den BE und Deine Daten
sind futsch!

Was ist wenn es keinen Updater gibt und der User die DB manuell
öffnet und offen lässt?!? Irgendwie reden wir aneinander vorbei ..

Egal wie man Updates einspielt, dieses Problem hat man bei einer
FileDB immer. Aber es laufen in diesem Fall zur backuptime keine
Clients mehr ;-).


Gruss
Anton

[Peter Steimann]

Hallo Anton

Post by Anton Huber
Hello Peter!

Post by Peter Steimann

Post by Anton Huber
Bei einem Projekt von mir habe ich ein Updateprogramm für die FEs
geschrieben. D.h. die Benutzer durften nicht mehr das FE direkt
öffnen sondern nur dieses Updt-Programm. Dieses Programm lädt
vom Fileserver das neue FE (falls vorhanden) herunter und öffnet
danach das FE.

Ehrlich gesagt, find ich das nicht gerade gut. Wenn Du die FE's lokal hältst
und beim Start eine Versionsprüfung machen würdest, würd mir das schon
wesentlich besser gefallen...

Ich denke da geht was quer ... ???
FEs liegen auf den Clients. Das Programm welches vorab (am Client)
gestartet wird überprüft ob eine neue Version am Fileserver liegt. Ist
dem so wird das 'neue' FE auf den Client geladen, wenn nicht wird
einfach das 'alte' FE auf dem Client gestartet.
Dieser Vorgang hat mal mit Access prinzipiell gar nichts zu tun ...
In diesem Fall ist es nicht nur ein FE. Es sind auch zusätzlich
diverse dlls und anderes Zeugs ...

Na jetzt gefällt mir das schon wesentlich besser;-) So wurde das ja auch
hier schon mehrmals diskutiert.

Post by Anton Huber

Post by Peter Steimann
Zudem hat das sachnellere Oeffnen den Nachteil, dass in eienr
Mehrbenutzer-Umgebung das FE immer langsamer wird, auch wenn die App nur
minimiert geöffnet und weggelegt wird.

Verstehe nicht ganz? Da wird nichts minimiert geöffnet?!?

Dein User öffnet den FE und schiebt den einach auf die Taskbar....

Post by Anton Huber
Updater wird gestartet -> kein neues FE da. O.k. altes FE am Client
wird gestartet.

Soweit jetzt klar

Post by Anton Huber
Nächter Tag: Updater wird gestartet -> neues FE da. O.k. FE
vom Server wird auf den Client geladen. Neues FE wird (lokal)
gestartet. FE bindet Tabellen vom BE ein. FE schliesst sich nach
dieser Aktion automatisch. Updater sartet mit kurzer Verzögerung
das FE (lokal) nochmals und schliesst sich danach selber.

Aber warum die Tabellen neu einbinden? Mappen die User unterschiedlich?
Würde noch etwas Zeit sparen, wenn Du die Tabellen schon eingebundenlassen
willst. Ansonsten Einbinden, wenn diese gebraucht werden undd ann wieder
trennen. (s.u.)

Post by Anton Huber
Wie gesagt dies ist die einzige Möglichkeit gewesen >>keine<<
Geschwindigkeitsverluste zu erhalten. Da der Zielpfad des
BEs variabel ist und die Tabellen erst beim Start eingebunden
werden. In allen anderen Fällen wurde es unerträglich langsam
bzw. es lagen auch Sperren auf DSes die nie 'berührt' wurden
(Soll heissen gleich am Anfang).
Dieses System läuft nun bereits 2 1/2 Jahre mit etwa 30 Clients
sehr stabil.

Stell ich ja auch nicht in Frage. Was aber auch nicht heisst, dass man das
Verfahren ab und an neu überdenken darf?-;)

Post by Anton Huber

Post by Peter Steimann
Abgesehen davon kan es auch sein, dass Deine Datensicherung schlapp macht,
wenn noch eine Connection zum BE offen ist. User lässt den PC nachts
laufen-Du machst die Sicherung-Tags darauf verhauts den BE und Deine Daten
sind futsch!

Was ist wenn es keinen Updater gibt und der User die DB manuell
öffnet und offen lässt?!? Irgendwie reden wir aneinander vorbei ..

Es geht um die Aussage, dass der Zugriff schneller ist, wenn die Tabellen
beim Start eingebunden werden und eingebunden bleiben. Dies trifft aber nur
auf 1 Client zu. Jetzt kommt das mit dem "minimiert starten". Die Tabellen
bleiben eingebunden, obwohl der Benutzer nix tut...und bremst die anderen.
Mit dem Updater selbst hat das natürlich gar nichts zu tun. Es ging imho um
2 verschiedene Kontexte .....

Post by Anton Huber
Egal wie man Updates einspielt, dieses Problem hat man bei einer
FileDB immer. Aber es laufen in diesem Fall zur backuptime keine
Clients mehr ;-).

Wie stellst Du das sicher? Lässt einer den Rechner laufen und hat die DB bei
nicht eingebundenen Tabellen auf der Taskleiste, ist das Deiner
Datensicherung wurscht und es passiert auch nix. Anderenfalls hast Du ein
Openfile auf demn Server und musst damit rechnen, dass Deine Datensicherung
nix Wert ist. Vielleicht solt ich hier noch etwas Werbung für mein Overkill
machen...-;)

Zusammenfassend: Imo ist die Anwendung in der Mehrbenutzer-Umgebung
schneller, wenn die Tabellen erst bei "Gebrauch" eingebunden und dann, ev.
über einen Timer, wieder getrennt werden. Die kleine Verzögerung kann man in
Kauf nehmen. Du hast weniger Unsicherheiten, was die Datensicherung
betrifft, falls sich der User nicht ausloggt.

[Anton Huber]

"Peter Steimann" threw this exception:

Hallo Peter!

Post by Peter Steimann

Post by Anton Huber

Post by Peter Steimann
Ehrlich gesagt, find ich das nicht gerade gut. Wenn Du die FE's lokal hältst
und beim Start eine Versionsprüfung machen würdest, würd mir das schon
wesentlich besser gefallen...

Ich denke da geht was quer ... ???
FEs liegen auf den Clients. Das Programm welches vorab (am Client)
gestartet wird überprüft ob eine neue Version am Fileserver liegt. Ist
dem so wird das 'neue' FE auf den Client geladen, wenn nicht wird
einfach das 'alte' FE auf dem Client gestartet.
Dieser Vorgang hat mal mit Access prinzipiell gar nichts zu tun ...
In diesem Fall ist es nicht nur ein FE. Es sind auch zusätzlich
diverse dlls und anderes Zeugs ...

Na jetzt gefällt mir das schon wesentlich besser;-) So wurde das ja auch
hier schon mehrmals diskutiert.

Ich habs auch noch nie anders gemacht und
auch nicht anders beschrieben ;-).

Post by Peter Steimann

Post by Anton Huber

Post by Peter Steimann
Zudem hat das sachnellere Oeffnen den Nachteil, dass in eienr
Mehrbenutzer-Umgebung das FE immer langsamer wird, auch wenn die App nur
minimiert geöffnet und weggelegt wird.

Verstehe nicht ganz? Da wird nichts minimiert geöffnet?!?

Dein User öffnet den FE und schiebt den einach auf die Taskbar....

Ja und ...
Nach Deinem Ansatz dürfte der User das FE nicht starten ...
Aber wie soll er dann darin arbeiten ??? ;-)
Aha O.k. jetzt begreife ich was Du meinst ...

Post by Peter Steimann

Post by Anton Huber
Nächter Tag: Updater wird gestartet -> neues FE da. O.k. FE
vom Server wird auf den Client geladen. Neues FE wird (lokal)
gestartet. FE bindet Tabellen vom BE ein. FE schliesst sich nach
dieser Aktion automatisch. Updater sartet mit kurzer Verzögerung
das FE (lokal) nochmals und schliesst sich danach selber.

Aber warum die Tabellen neu einbinden? Mappen die User unterschiedlich?
Würde noch etwas Zeit sparen, wenn Du die Tabellen schon eingebundenlassen
willst. Ansonsten Einbinden, wenn diese gebraucht werden undd ann wieder
trennen. (s.u.)

Hm ...
1) In >>gewisser<< Weise ein Relikt, da zuvor bei diesem Kunden
alles über Netzlaufwerke realisiert wurde (Die User kannten
noch nicht mal die 'Netzwerkumgebung'. (Übrigens der
Admin vor Ort auch nicht ;-) ).

2) Updates: Mich kümmerts ja nicht wo die Ihr BE liegen haben.
Ich mache mir ein FE-Zip und entpacke es in den Updateordner.
Alles andere geht automatisch, für mich wesentlich angenehmer.
Vor allem da ich dies über eine remoteshell mit nicht all zu
dicker Anbindung mache.

Post by Peter Steimann

Post by Anton Huber
Wie gesagt dies ist die einzige Möglichkeit gewesen >>keine<<
Geschwindigkeitsverluste zu erhalten. Da der Zielpfad des
BEs variabel ist und die Tabellen erst beim Start eingebunden
werden. In allen anderen Fällen wurde es unerträglich langsam
bzw. es lagen auch Sperren auf DSes die nie 'berührt' wurden
(Soll heissen gleich am Anfang).
Dieses System läuft nun bereits 2 1/2 Jahre mit etwa 30 Clients
sehr stabil.

Stell ich ja auch nicht in Frage. Was aber auch nicht heisst, dass man das
Verfahren ab und an neu überdenken darf?-;)

Doch alles darf man ;-). Meist ist es ja so das man mit der Zeit
'laufendes' einfach nicht mehr überdenkt da es ja noch so viel
andere Arbeit gibt ...

Post by Peter Steimann

Post by Anton Huber
Was ist wenn es keinen Updater gibt und der User die DB manuell
öffnet und offen lässt?!? Irgendwie reden wir aneinander vorbei ..

Es geht um die Aussage, dass der Zugriff schneller ist, wenn die Tabellen
beim Start eingebunden werden und eingebunden bleiben. Dies trifft aber nur
auf 1 Client zu. Jetzt kommt das mit dem "minimiert starten". Die Tabellen
bleiben eingebunden, obwohl der Benutzer nix tut...und bremst die anderen.
Mit dem Updater selbst hat das natürlich gar nichts zu tun. Es ging imho um
2 verschiedene Kontexte .....

Ja, O.k., ich verstehe Dich nicht ganz, Du mich nicht ganz ... ;-).

Post by Peter Steimann

Post by Anton Huber
Egal wie man Updates einspielt, dieses Problem hat man bei einer
FileDB immer. Aber es laufen in diesem Fall zur backuptime keine
Clients mehr ;-).

Wie stellst Du das sicher? Lässt einer den Rechner laufen und hat die DB bei
nicht eingebundenen Tabellen auf der Taskleiste, ist das Deiner
Datensicherung wurscht und es passiert auch nix. Anderenfalls hast Du ein
Openfile auf demn Server und musst damit rechnen, dass Deine Datensicherung
nix Wert ist. Vielleicht solt ich hier noch etwas Werbung für mein Overkill
machen...-;)

Einfach; alle Arbeitsplätze werden vom backupserver vor der Sicherung
remote runtergefahren. Am FE hängt eine dll mit einem Hook der die
QueryEndSession/EndSession-Message mitprotokolliert und mein FE
'zurückruft'. Das FE beendet sich (fast ;-) ) immer Ordnungsgemäss.

Post by Peter Steimann
Zusammenfassend: Imo ist die Anwendung in der Mehrbenutzer-Umgebung
schneller, wenn die Tabellen erst bei "Gebrauch" eingebunden und dann, ev.
über einen Timer, wieder getrennt werden. Die kleine Verzögerung kann man in
Kauf nehmen. Du hast weniger Unsicherheiten, was die Datensicherung
betrifft, falls sich der User nicht ausloggt.

Also die Idee hört sich gut an.
Aber:
1) Komme ich dann nicht wieder mit eigenwilligen DS-Sperren
(wie anfangs beschrieben) in Kontakt.
2) Das FE ist ein durchwachsenes 'Ding'. Ist halt doch viel
Aufwand alle Userzugriffe mit zu protokollieren und entsprechend
zu reagieren.
Die unterschiedlichen Abfragen/Formalure/Dialoge erfordern ja
unterschiedliche Tabellen. Wäre zwar es eine Herausforderung
da etwas zu schreiben, aber ob ich da nicht mal in Zeitnot gerate.
3) Oder meinst Du eher etwas in der Richtung von all-or-nothing
beim Tabelleneinbinden?
4) Eine Tabelle muss aber ohnehin immer geöffnet bleiben
(persistente Dummytab). Was ist mit dieser? Die kann ja
dann auch Probleme bereiten, oder etwa nicht?
5) Stellen sich gleich wieder die Fragen, was ist ein vernüftiger
timeout, wie definiert man ob der User arbeitet oder nicht.

Gibts Erfahrungswerte wie gross der Geschwindigkeitsvorteil ist?
Gibts Erfahrungswerte um wieviel höher die NW-Last ist?


Gruss und Dank
Anton

[Peter Steimann]

Hallo Anton

Post by Anton Huber
Hallo Peter!

Post by Peter Steimann

Post by Anton Huber

Post by Peter Steimann
Ehrlich gesagt, find ich das nicht gerade gut. Wenn Du die FE's lokal hältst
und beim Start eine Versionsprüfung machen würdest, würd mir das schon
wesentlich besser gefallen...

Ich denke da geht was quer ... ???
FEs liegen auf den Clients. Das Programm welches vorab (am Client)
gestartet wird überprüft ob eine neue Version am Fileserver liegt. Ist
dem so wird das 'neue' FE auf den Client geladen, wenn nicht wird
einfach das 'alte' FE auf dem Client gestartet.
Dieser Vorgang hat mal mit Access prinzipiell gar nichts zu tun ...
In diesem Fall ist es nicht nur ein FE. Es sind auch zusätzlich
diverse dlls und anderes Zeugs ...

Na jetzt gefällt mir das schon wesentlich besser;-) So wurde das ja auch
hier schon mehrmals diskutiert.

Ich habs auch noch nie anders gemacht und
auch nicht anders beschrieben ;-).

AAehm, Du hattest es gar nicht beschrieben. Wenigstens nicht in diesem
Thread...

Post by Anton Huber

Post by Peter Steimann

Post by Anton Huber

Post by Peter Steimann
Zudem hat das sachnellere Oeffnen den Nachteil, dass in eienr
Mehrbenutzer-Umgebung das FE immer langsamer wird, auch wenn die App nur
minimiert geöffnet und weggelegt wird.

Verstehe nicht ganz? Da wird nichts minimiert geöffnet?!?

Dein User öffnet den FE und schiebt den einach auf die Taskbar....

Ja und ...
Nach Deinem Ansatz dürfte der User das FE nicht starten ...

Wieso dürfte er nicht? Logisch, weil es keinen Sinn macht, den FE zu öffnen
und dann einfach "runterzulegen". Auf die Logik der Benutzer baue ich aber
nicht-;)

Post by Anton Huber
Aber wie soll er dann darin arbeiten ??? ;-)
Aha O.k. jetzt begreife ich was Du meinst ...

Post by Peter Steimann

Post by Anton Huber
Nächter Tag: Updater wird gestartet -> neues FE da. O.k. FE
vom Server wird auf den Client geladen. Neues FE wird (lokal)
gestartet. FE bindet Tabellen vom BE ein. FE schliesst sich nach
dieser Aktion automatisch. Updater sartet mit kurzer Verzögerung
das FE (lokal) nochmals und schliesst sich danach selber.

Aber warum die Tabellen neu einbinden? Mappen die User unterschiedlich?
Würde noch etwas Zeit sparen, wenn Du die Tabellen schon eingebundenlassen
willst. Ansonsten Einbinden, wenn diese gebraucht werden undd ann wieder
trennen. (s.u.)

Hm ...
1) In >>gewisser<< Weise ein Relikt, da zuvor bei diesem Kunden
alles über Netzlaufwerke realisiert wurde (Die User kannten
noch nicht mal die 'Netzwerkumgebung'. (Übrigens der
Admin vor Ort auch nicht ;-) ).

OK. UNC wäre da eine Alternative. Obwohl ich da auch schon von Problemen
gehört habe, was die Performance anbelangt

Post by Anton Huber
2) Updates: Mich kümmerts ja nicht wo die Ihr BE liegen haben.

Mich grundsätzlich auch nicht. Wenn ich aber Vorteile sehe, ist es doch
meine Aufgabe, mich darum zu kümmern...Bestehst Du also auf immer verknüpfte
Tabellen, fällt dann der Einbindungsjob weg. Bei mir sind das etwa 100
Tabellen, das macht sich dann schon bemerkbar.

Post by Anton Huber
Ich mache mir ein FE-Zip und entpacke es in den Updateordner.
Alles andere geht automatisch, für mich wesentlich angenehmer.

Klar

Post by Anton Huber
Vor allem da ich dies über eine remoteshell mit nicht all zu
dicker Anbindung mache.

Post by Peter Steimann

Post by Anton Huber
Wie gesagt dies ist die einzige Möglichkeit gewesen >>keine<<
Geschwindigkeitsverluste zu erhalten. Da der Zielpfad des
BEs variabel ist und die Tabellen erst beim Start eingebunden
werden. In allen anderen Fällen wurde es unerträglich langsam
bzw. es lagen auch Sperren auf DSes die nie 'berührt' wurden
(Soll heissen gleich am Anfang).
Dieses System läuft nun bereits 2 1/2 Jahre mit etwa 30 Clients
sehr stabil.

Stell ich ja auch nicht in Frage. Was aber auch nicht heisst, dass man das
Verfahren ab und an neu überdenken darf?-;)

Doch alles darf man ;-). Meist ist es ja so das man mit der Zeit
'laufendes' einfach nicht mehr überdenkt da es ja noch so viel
andere Arbeit gibt ...

BEG. Das hat was;-)

Post by Anton Huber

Post by Peter Steimann

Post by Anton Huber
Was ist wenn es keinen Updater gibt und der User die DB manuell
öffnet und offen lässt?!? Irgendwie reden wir aneinander vorbei ..

Es geht um die Aussage, dass der Zugriff schneller ist, wenn die Tabellen
beim Start eingebunden werden und eingebunden bleiben. Dies trifft aber nur
auf 1 Client zu. Jetzt kommt das mit dem "minimiert starten". Die Tabellen
bleiben eingebunden, obwohl der Benutzer nix tut...und bremst die anderen.
Mit dem Updater selbst hat das natürlich gar nichts zu tun. Es ging imho um
2 verschiedene Kontexte .....

Ja, O.k., ich verstehe Dich nicht ganz, Du mich nicht ganz ... ;-).

Macht nix. Wir sind ja auch nicht verheiratet;-)

Post by Anton Huber

Post by Peter Steimann

Post by Anton Huber
Egal wie man Updates einspielt, dieses Problem hat man bei einer
FileDB immer. Aber es laufen in diesem Fall zur backuptime keine
Clients mehr ;-).

Wie stellst Du das sicher? Lässt einer den Rechner laufen und hat die DB bei
nicht eingebundenen Tabellen auf der Taskleiste, ist das Deiner
Datensicherung wurscht und es passiert auch nix. Anderenfalls hast Du ein
Openfile auf demn Server und musst damit rechnen, dass Deine
Datensicherung
nix Wert ist. Vielleicht solt ich hier noch etwas Werbung für mein Overkill
machen...-;)

Einfach; alle Arbeitsplätze werden vom backupserver vor der Sicherung
remote runtergefahren. Am FE hängt eine dll mit einem Hook der die
QueryEndSession/EndSession-Message mitprotokolliert und mein FE
'zurückruft'. Das FE beendet sich (fast ;-) ) immer Ordnungsgemäss.

So hab ich das noch nie versucht. Dafür hab ich mein Overkill (ohne DLL),
und damit gabs noch überhaupt nie ein Problem-;)

Post by Anton Huber

Post by Peter Steimann
Zusammenfassend: Imo ist die Anwendung in der Mehrbenutzer-Umgebung
schneller, wenn die Tabellen erst bei "Gebrauch" eingebunden und dann, ev.
über einen Timer, wieder getrennt werden. Die kleine Verzögerung kann man in
Kauf nehmen. Du hast weniger Unsicherheiten, was die Datensicherung
betrifft, falls sich der User nicht ausloggt.

Also die Idee hört sich gut an.
1) Komme ich dann nicht wieder mit eigenwilligen DS-Sperren
(wie anfangs beschrieben) in Kontakt.

Ich konnte das Problem bei mir bisher eh noch nie beobachten. Vielleicht
deshalb, weil ich grundsätzlich nicht mit Recordlocking arbeite-;)

Post by Anton Huber
2) Das FE ist ein durchwachsenes 'Ding'. Ist halt doch viel
Aufwand alle Userzugriffe mit zu protokollieren und entsprechend
zu reagieren.

Im Bezug auf die hier diskutierten Ansätze musst Du das auch nicht

Post by Anton Huber
Die unterschiedlichen Abfragen/Formalure/Dialoge erfordern ja
unterschiedliche Tabellen. Wäre zwar es eine Herausforderung
da etwas zu schreiben, aber ob ich da nicht mal in Zeitnot gerate.
3) Oder meinst Du eher etwas in der Richtung von all-or-nothing
beim Tabelleneinbinden?

Ja

Post by Anton Huber
4) Eine Tabelle muss aber ohnehin immer geöffnet bleiben

Warum?

Post by Anton Huber
(persistente Dummytab). Was ist mit dieser? Die kann ja
dann auch Probleme bereiten, oder etwa nicht?

Ja, klar. Somit hast Du ja auch eine Connection zum BE

Post by Anton Huber
5) Stellen sich gleich wieder die Fragen, was ist ein vernüftiger
timeout, wie definiert man ob der User arbeitet oder nicht.

Imho im Minutenbereich. Die Frage stell ich mir übrigens auch jedesmal, wenn
ich beim Online-Banking in einen Sitzungs-Timesout laufe

Post by Anton Huber
Gibts Erfahrungswerte wie gross der Geschwindigkeitsvorteil ist?

Kannst Du selber ausprobieren: 1. User ist drin, 2. User ebenfalls und
arbeitet. 2. User abmelden und mit dem 1. User dieselben Arbeitsschritte
ausführen. Möglichst natürlich mit aufwendigen Forms oder mit
Verarbeitungsjobs.

Post by Anton Huber
Gibts Erfahrungswerte um wieviel höher die NW-Last ist?

In welcher Grösse misst Du?-;) Imho hält das der Server aber locker aus. Es
geht ja nur ums Tabellen einbinden...

[Anton Huber]

"Peter Steimann" threw this exception:

Hello Peter!

Post by Peter Steimann

Post by Anton Huber
Ich habs auch noch nie anders gemacht und
auch nicht anders beschrieben ;-).

AAehm, Du hattest es gar nicht beschrieben. Wenigstens nicht in diesem
Thread...

Jetzt entäuscht Du mich etwas:

<snip>
Bei einem Projekt von mir habe ich ein Updateprogramm für die FEs
geschrieben. D.h. die Benutzer durften nicht mehr das FE direkt
öffnen sondern nur dieses Updt-Programm. Dieses Programm lädt
vom Fileserver das neue FE (falls vorhanden) herunter und öffnet
danach das FE.
In dem nacktem neuen FE werden dann zuerst die Tabellen vom BE
programmatisch eingebunden und das persistente RS geöffnet.
</snap>

Schnell und dirty aber es kommt das selbe dabei heraus ...

Post by Peter Steimann

Post by Anton Huber
Hm ...
1) In >>gewisser<< Weise ein Relikt, da zuvor bei diesem Kunden
alles über Netzlaufwerke realisiert wurde (Die User kannten
noch nicht mal die 'Netzwerkumgebung'. (Übrigens der
Admin vor Ort auch nicht ;-) ).

OK. UNC wäre da eine Alternative. Obwohl ich da auch schon von Problemen
gehört habe, was die Performance anbelangt

Egal, Netzlaufwerke wurden ohnehin abgedreht da sich
diese immer wieder 'Offline-ten' und es ständig zu
NW-Fehler kam. Jetzt gibts es nur mehr UNC.

Post by Peter Steimann

Post by Anton Huber
1) Komme ich dann nicht wieder mit eigenwilligen DS-Sperren
(wie anfangs beschrieben) in Kontakt.

Ich konnte das Problem bei mir bisher eh noch nie beobachten. Vielleicht
deshalb, weil ich grundsätzlich nicht mit Recordlocking arbeite-;)

O.k. So is es halt im Leben gleiche Voraussetzungen unterschiedliche
Ergebnisse. Hier gehts auch nicht um rs-locking. Ich hab mich jetzt
nochmal etwas gespielt. Da ich mir das damalige Scenario (für meine
Kinder und Kindeskinder ;-) ) aufgehoben habe.

BE Server
1.FE Client A
2.FE Client B

1) Beide FEs sind ohne Tabs.

Client A startet und bindet Tabs vom BE ein ...
Client B startet und bindet Tabs vom BE ein ...

Client A hat noch überhaupt nichts gemacht
Client B will eine Adresse öffnen Access behauptet
der DS sei von einem anderen User gesperrt worden

Am BE in die Tabelle rein tatsächlich man kann den DS
auch in der Tab nicht bearbeiten.

Client A schliesst. DS noch immer gesperrt
Client B schliesst. DS frei klar.
(Auch in umgekehrter Reihenfolge aller Parameter
(start/schliessen/etc.). Kein Unterschied.

Es sind einfach wahllos verschiedenste DS gesperrt!


2) Beide FEs sind ohne Tabs

Client A startet und bindet Tabs vom BE ein ...
Client A schliesst und startet

Client B startet und bindet Tabs vom BE ein ...
Client A schliesst und startet

Problem gegessen ...

Post by Peter Steimann

Post by Anton Huber
4) Eine Tabelle muss aber ohnehin immer geöffnet bleiben

Warum?

Da sonst alles zum Vergessen ist (Geschwindigkeit) -> man google.

Scheinbar hast Du das Glück durch irgendwelche Umstände von
allen Problemen im Accessmehrbenutzerbetrieb verschont zu
bleiben ;-)).


Gruss
Anton

[Peter Steimann]

Hallo Anton

Post by Anton Huber
Hello Peter!

Post by Peter Steimann

Post by Anton Huber
Ich habs auch noch nie anders gemacht und
auch nicht anders beschrieben ;-).

AAehm, Du hattest es gar nicht beschrieben. Wenigstens nicht in diesem
Thread...

<snip>
Bei einem Projekt von mir habe ich ein Updateprogramm für die FEs
geschrieben. D.h. die Benutzer durften nicht mehr das FE direkt
öffnen sondern nur dieses Updt-Programm. Dieses Programm lädt
vom Fileserver das neue FE (falls vorhanden) herunter und öffnet
danach das FE.
In dem nacktem neuen FE werden dann zuerst die Tabellen vom BE
programmatisch eingebunden und das persistente RS geöffnet.
</snap>

Jaaaa. Das mit der Versionsprüfung hier ist aber auch sehr leicht zu
überlesen-;)

Post by Anton Huber

Post by Peter Steimann

Post by Anton Huber
4) Eine Tabelle muss aber ohnehin immer geöffnet bleiben

Warum?

Da sonst alles zum Vergessen ist (Geschwindigkeit) -> man google.

Aber genau da wirds doch interessant. Ich vertrete eben genau nicht diese
These! Das Testprocedere hab ich ja schon geschildert. Und auch warum.
(Geschwindigkeit in der Mehrbenutzerumgebung, Datensicherung...) Natürlich
gehte s länger, wenn Du erstmal die Tabellen einbinden musst. Hat halt aber
eben die anderen, ebenfalls beschriebenen Vorteile.

Post by Anton Huber
Scheinbar hast Du das Glück durch irgendwelche Umstände von
allen Problemen im Accessmehrbenutzerbetrieb verschont zu
bleiben ;-)).

Recordlocking funktioniert ja erst ab A2000. Bei A97 wärst Du ganz schön auf
die Nase gefallen. (Locking eines Memorybereiches und nicht eines einzelnen
Datensatzes) Ich setze halt nur das ein, wo ich weiss, dass es 100%
funktioniert. Wer braucht schon Recordlocking....wenn's den unbedingt sein
muss, kann man das auch via Code nachstellen...und bleibt dann von den
beschriebenen Problemen verschont. Dann setze ich A2000 nur noch da ein, wo
der Kunde es unbedingt will, und lehne jegliche Verantwortung zum vornherein
ab. (lieber ne AXP-Runtime, dann kann ich dafür geradestehen...)

Dann verwende ich absolut keine OCX'e. So habe ich es immerhin geschafft,
über 100 Installationen in Netzwerkumgebungen zu machen, ohne je auf solche
von Dir geschilderten Probleme zu stossen. Mit Glück hat das wenig zu tun.


Gruss

Peter

[Anton Huber]

"Peter Steimann" threw this exception:

Hallo Peter!

Post by Peter Steimann

Post by Anton Huber

Post by Peter Steimann

Post by Anton Huber
4) Eine Tabelle muss aber ohnehin immer geöffnet bleiben

Warum?

Da sonst alles zum Vergessen ist (Geschwindigkeit) -> man google.

Aber genau da wirds doch interessant. Ich vertrete eben genau nicht diese
These! Das Testprocedere hab ich ja schon geschildert. Und auch warum.
(Geschwindigkeit in der Mehrbenutzerumgebung, Datensicherung...) Natürlich
gehte s länger, wenn Du erstmal die Tabellen einbinden musst. Hat halt aber
eben die anderen, ebenfalls beschriebenen Vorteile.

These hin oder her. Ich habe ja bereits in dem anderen Beitrag
beschrieben wie Access einbebundene Tabellen handhabt.
Eine eingebundene Tabelle erstellt kein lockfile am BE. Erst
der Zugriff auf die Tabelle erstellt ein lockfile. Sobal der Zugriff
beendet ist löscht Access das lockfile sofort wieder.

Durch diesen Umstand:
- verstehe ich auch Deine Bemühungen mit entbinden/binden
der Tabellen nicht.
- ist es auch klar warum ohne einen persistenten RS auf
das BE der Zugriff ehlends langsam ist. Das FE muss immer
wieder eine lockfile anlegen (man google (NW, timeout)).
Es kann eigentlich nicht anders sein ...

Selbst laut M$:
http://support.microsoft.com/kb/889588/en-us
(Optimize the Access or Jet database engine-based
database routines and methods).

Post by Peter Steimann

Post by Anton Huber
Scheinbar hast Du das Glück durch irgendwelche Umstände von
allen Problemen im Accessmehrbenutzerbetrieb verschont zu
bleiben ;-)).

Recordlocking funktioniert ja erst ab A2000. Bei A97 wärst Du ganz schön auf
die Nase gefallen. (Locking eines Memorybereiches und nicht eines einzelnen
Datensatzes) Ich setze halt nur das ein, wo ich weiss, dass es 100%
funktioniert.

Diese DB wurde auschliesslich für AXP erstellt. Aber wie gesagt (bitte
lese genau). Die DS sind gesperrt *bevor* irgendein user überhaupt
irgendwas gemacht hat. Es wird nichts vom User bzw. programmatisch
gesperrt. Dennoch sind die Sperren da gewesen, ich kann ja nichts
dafür, war/ist halt so ...

Und: Ich überlege vor dem Einsatz von Funktionen schon was dabei
passiert, und prüfe 1000 x bevor ich es ausliefere, ergo falle ich nie
auf die Nase (beim Ausliefern ;-) ).

Post by Peter Steimann
Wer braucht schon Recordlocking....wenn's den unbedingt sein
muss, kann man das auch via Code nachstellen...und bleibt dann von den
beschriebenen Problemen verschont.

Nochmal es wird nichts per user oder code gelocked (siehe oben).

Post by Peter Steimann
Dann setze ich A2000 nur noch da ein, wo
der Kunde es unbedingt will, und lehne jegliche Verantwortung zum vornherein
ab. (lieber ne AXP-Runtime, dann kann ich dafür geradestehen...)

Ich habe A2K, AXP, etc., und alles so gemacht dass ich auch dafür
grade stehen kann ... ;-)

Post by Peter Steimann
Dann verwende ich absolut keine OCX'e.

Ich auch fast nicht. Habe mir fast alle selbst nachgebaut
(Kalender, ListView, ...). Nur beim Webbrowserctrl. bin ich
noch nicht dazu gekommen ...

Post by Peter Steimann
So habe ich es immerhin geschafft,
über 100 Installationen in Netzwerkumgebungen zu machen, ohne je auf solche
von Dir geschilderten Probleme zu stossen. Mit Glück hat das wenig zu tun.

Tja bei einer Einschränkung auf 'nur' Acc97 ist der Vergleich unfair.
Den selbst in der KB stehen 100te Artikel drinnen, welche Probleme
es in > Acc97 gibt die es in Acc97 so nie gegeben hat.

Aber deswegen kann ich ja nicht auf der Stelle treten. Wenn heute
einer zu mir kommt und sagt er will eine DB-Lösung für OfficeXP,
sage ich sicher nicht: Lösche XP und spiele 97 rauf dann bekommst
was schönes von mir ...
Nein, natürlich nicht, ich habe ja bereits Lösungen für die Probleme
von A2K und AXP ...
Und ich werde Ihm auch nicht eine runtime unterjubeln wenn er
ohnehin Lizenzen für Acc gezahlt hat, da die runtime ja wieder
Einschränkungen unterliegt ...

Überhaupt kommt es mir in dieser NG manchmal so vor als ob
der eine oder andere, Kunden eigentlich nicht nötig hat.
Wenn der Kunde was will sage ich nicht sowas geht nicht, sondern
ich setzte mich hin und erstelle/versuche eine Lösung die den
Voraussetzungen beim Kunden erfüllen. Nein sagen kann ich
danach immer noch, falls meine erarbeitete Lösung nicht
zuverlässig ist, oder ich empfehle eine SQL-Server-Variante mit
Acc als FE, oder auch ganz was anderes, aber das gehört hier
nicht her ...


Gruss
Anton

[Anton Huber]

"Peter Steimann" threw this exception:

Hallo Peter!

Post by Peter Steimann
Zusammenfassend: Imo ist die Anwendung in der Mehrbenutzer-Umgebung
schneller, wenn die Tabellen erst bei "Gebrauch" eingebunden und dann, ev.
über einen Timer, wieder getrennt werden. Die kleine Verzögerung kann man in
Kauf nehmen. Du hast weniger Unsicherheiten, was die Datensicherung
betrifft, falls sich der User nicht ausloggt.

Das bringt mich aber irgend wie auf folgendes:

1) Bei M$ tappt man ja meistens im Dunkeln.
2) Was ist eigentlich eine eingebundene Tabelle? Ein Werkzeug für
den 'unbefleckten' User oder eine richtige connection.

Da ja schon oft über die Probleme des lockings bei Access
diskutiert wurde und immer wieder die persistenten RSes
Abhilfe schaffen, denke ich das eine eingebundene Tabelle
keine echte connection darstellt.

Kurz überprüft: Nur das einbinden der Tabellen ohne einen
Zugriff darauf erstellt kein lockfile am BE. BE lässt sich
ohne weiters exklusiv öffnen.

Gleiches gilt für: BE verschieben, FE öffnen, FE meckert
erst bei dem Zugriff auf die Tabelle.

Müsste noch Ausbrobieren was ethereal dazu 'sagt'.

Müsste es dann nicht so sein, dass Access den lock wieder
fallen lässt wenn ein rs im FE geschlossen wird? Wieder
auf das 'persistente' rs bezogen: Ja, wahrscheinlich.

Kurz ausprobiert:
FE öffnen - kein lock am BE
Tabelle im FE öffnen - lock am BE
Tabelle im FE schliessen - lock am BE verschwindet
innerhalb weniger Sekunden

IMHO hast Du etwas nachprogrammiert was Access ansich
in einer Mehrbenutzerumgebung bereits leistet.

Daher kann ich mir zu Deinem Vorschlag nicht wirklich irgendwelche
Vorteile ableiten. Ausser: Der User hält ein rs irgendwie offen und
geht nach Hause, hier könnte man eventuell dafür sorge tragen das
alle RSes nach einer betimmten Inaktivität geschlossen werden. Aber
auch hier stellt sich die Frage wie definiert man Inaktivität. User
liest einen längeren Text, soll ich ihm einfach den Hahn nach 20
Minuten zudrehen?!?


Gruss
Anton

[Anton Huber]

Post by Anton Huber

Post by Peter Steimann
Zusammenfassend: Imo ist die Anwendung in der Mehrbenutzer-Umgebung
schneller, wenn die Tabellen erst bei "Gebrauch" eingebunden und dann, ev.

Erfahrung oder auch was nachlesbares?

Post by Anton Huber

Post by Peter Steimann
über einen Timer, wieder getrennt werden. Die kleine Verzögerung kann man in
Kauf nehmen. Du hast weniger Unsicherheiten, was die Datensicherung
betrifft, falls sich der User nicht ausloggt.

[...]
IMHO hast Du etwas nachprogrammiert was Access ansich
in einer Mehrbenutzerumgebung bereits leistet.
Daher kann ich mir zu Deinem Vorschlag nicht wirklich irgendwelche
Vorteile ableiten. Ausser: Der User hält ein rs irgendwie offen und
geht nach Hause, hier könnte man eventuell dafür sorge tragen das
alle RSes nach einer betimmten Inaktivität geschlossen werden. Aber
auch hier stellt sich die Frage wie definiert man Inaktivität. User
liest einen längeren Text, soll ich ihm einfach den Hahn nach 20
Minuten zudrehen?!?

STOPP, ganz falsch,
Wenn ich mir ansehe was ich bis jetzt mit frisch eingebundenen
Tabellen erlebt habe kann ich nur davon abraten Tabellen
bei Bedarf ein/auszubinden.
Denn scheinbar wird eine frisch eingebundene Tabelle in
Access anders behandelt als eine die bereits vor dem
Start eingebunden war (Du bringst mich ganz durcheinander ;-) ).

Wo wir wieder am Anfang wären (nicht umsonst habe ich mir damals
die Nächte um die Ohren geschlagen um das eigenartige Verhalten
von frisch eingebundenen Tabellen im Mehrbenutzerbetrieb zu
'ergründen').

...


Gruss
Anton

[Peter Steimann]

Post by Anton Huber

Post by Anton Huber

Post by Peter Steimann
Zusammenfassend: Imo ist die Anwendung in der Mehrbenutzer-Umgebung
schneller, wenn die Tabellen erst bei "Gebrauch" eingebunden und dann, ev.

Erfahrung oder auch was nachlesbares?

Erfahrung. Und einfach nachvollziehbar. Nachlesen kannste ja hier;-)

Post by Anton Huber

Post by Anton Huber

Post by Peter Steimann
über einen Timer, wieder getrennt werden. Die kleine Verzögerung kann man in
Kauf nehmen. Du hast weniger Unsicherheiten, was die Datensicherung
betrifft, falls sich der User nicht ausloggt.

[...]
IMHO hast Du etwas nachprogrammiert was Access ansich
in einer Mehrbenutzerumgebung bereits leistet.
Daher kann ich mir zu Deinem Vorschlag nicht wirklich irgendwelche
Vorteile ableiten. Ausser: Der User hält ein rs irgendwie offen und
geht nach Hause, hier könnte man eventuell dafür sorge tragen das
alle RSes nach einer betimmten Inaktivität geschlossen werden. Aber
auch hier stellt sich die Frage wie definiert man Inaktivität. User
liest einen längeren Text, soll ich ihm einfach den Hahn nach 20
Minuten zudrehen?!?

STOPP, ganz falsch,
Wenn ich mir ansehe was ich bis jetzt mit frisch eingebundenen
Tabellen erlebt habe kann ich nur davon abraten Tabellen
bei Bedarf ein/auszubinden.
Denn scheinbar wird eine frisch eingebundene Tabelle in
Access anders behandelt als eine die bereits vor dem
Start eingebunden war (Du bringst mich ganz durcheinander ;-) ).

Auch das wäre mir neu

Post by Anton Huber
Wo wir wieder am Anfang wären (nicht umsonst habe ich mir damals
die Nächte um die Ohren geschlagen um das eigenartige Verhalten
von frisch eingebundenen Tabellen im Mehrbenutzerbetrieb zu
'ergründen').

Bisher noch keine Probleme hier. A2000 weiss ich nich, ansonsten ab XP bei
mir problemlos

Gruss

Peter