Probleme beim Mehrfachzugriff auf Access

Computer: Software & Programmierung Microsoft Access
#1

Hallo

Folgendes Problem tritt derzeit bei mir auf:
Ich habe eine Acces-Datenbank als Frontend- Backendlösung auf die mehrere User gleichzeitig in einem Datenbereich arbeiten. Nun passiert es, das z.B. User1 einen neuen Datensatz anlegt und damit User2 und/oder User3 blockiert. Das äußert sich i.d.R. so, das der Cursor sehr verhalten bis gar nicht reagiert. Meist solange bis User1 aus diesem Datensatz raus ist. Ab und zu erscheint mal eine Fehlermeldung das der DS derzeit gesperrt ist und von … bearbeitet wird.
Dieser Fehler tritt wechselweise im gesamten Netz auf und auch in verschiedenen Bereichen der Datenbank, ist also weder Rechner- noch Tabellenabhängig

In den Optionen und auch in den Formularen steht die Datensatzsperrung auf bearbeiteter Datensatz.
Gibt es irgendwelche Einstellungen die diese Behinderungen minimieren oder gar ganz abschalten?

Gruß Matthias

#2

Hallo Matthias,

Ich habe eine Acces-Datenbank

welches Access denn?

als Frontend- Backendlösung auf die mehrere User gleichzeitig in einem Datenbereich arbeiten.

das Backend liegt auf einem eigenen MS-Server mit schnellen SATA Platten und min 4 GB RAM!?

Nun passiert es, das z.B. User1 einen neuen Datensatz anlegt
und damit User2 und/oder User3 blockiert.

User1 sperrt die ganze Tabelle! = falsche Programmierung

Das äußert sich i.d.R. so, das der Cursor sehr verhalten bis gar nicht reagiert.

Server und/oder Netz überlastet!?

Meist solange bis User1 aus diesem Datensatz raus ist.

sehr lahmer Server/Netzwerk!

Ab und zu erscheint mal eine Fehlermeldung das der DS
derzeit gesperrt ist und von … bearbeitet wird.

= Server konnte noch ein paar Bits im RAM frei machen und die Meldung senden :frowning:
= zu wenig RAM
= SQL/Abfragen zu groß/umfangreich

Dieser Fehler tritt wechselweise im gesamten Netz auf und auch
in verschiedenen Bereichen der Datenbank, ist also weder
Rechner- noch Tabellenabhängig

nun ja, abhängig vom Server -> Festplatte -> RAM, so wie das bei Datenbanken halt üblich ist.

In den Optionen und auch in den Formularen steht die
Datensatzsperrung auf bearbeiteter Datensatz.

tja, vermutlich nur dort!

Gibt es irgendwelche Einstellungen die diese Behinderungen
minimieren oder gar ganz abschalten?

ohne zu wissen, welche Version von Access du hast nur pauschal:

  • prüfe die Grundeinstellungen von Access bei JEDEM Frontend.
  • Speziell die Einstellungen für die Sperrungen.
  • verlege das Backend auf einen eigenen Server! mit schneller Platte und viel RAM (CPU ist nicht wichtig!)

Abschalten: würde ich nicht wagen, wenn dir die Daten wichtig sind :frowning:

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)

#3

Hallo Matthias,
je nachdem welche Version du benutzt ist das Sperrverhalten in Access unterschiedlich. Ich gehe aber mal davon aus, dass du eine Version > Access2000 hast.

Probier einfach mal in den Optionen „Keine Sperrung“. Dann wird das optimistische Sperrverfahren angewendet, welches in der Regel zu einem besserem Verhalten im Mehrbenutzer betrieb führt.
Gesperrt wird erst beim speichern des Datensatzes und nicht schon während der Bearbeitung.

Da die Sperren korrekterweise im Dateisystem gesetzt werden ist es wichtige, dass das Serverbetriebssystem diese auch 100%ig unterstützt. Das betone ich weil ich mit Samba bzw. unixbasierten Dateisystemen in der Vergangenheit zum Teil sehr wohl Probleme hatte.

Ein Server mit schneller Platte und schnellem Netzwerk hilft. Mehr RAM im Server bringt aber nichts, da schließlich die Daten durch den Client aus der mdb-Datei gelesen werden und nicht durch einen Serverprocess.

Gruss
Joey

#4

Hallo Wolfgang

Danke für Deine Antwort
Hätte nicht geglaubt, dass die Ursache derart Hardwareabhängig ist.
Dennoch ein paar Antworten auf deine Fragen:
Wir fahren derzeit noch Access97, stelle aber gerade auf 2007 um…
Der Server hat 2 GB, wobei schätzungsweise 90% des Datentraffics durch Access entstehen dürften.
Das Netzwerk für die Hauptuser ist auf 1GB ausgerichtet.
Die Einstellungen an den Frontend haben wir geprüft - ohne Ergebnis, wobei ich mir halt nicht sicher war, ob die Einstellung „Bearbeiteter Datensatz“ die richtige war.
Die Abfragen im Frontend sind nicht ohne, aber genau die damit erzeugten Infos brauchen meine Kollegen. Wobei diese Abfragen i.d.R. an anderer Stelle oder erst nach dem Anlegen des DS gebraucht werden (z.B. in Pull-Down-Feldern oder in Berichten)
Fazit:
Werde mich auf jeden Fall um einen neuen Server kümmern.
Zusatzfrage:
Würde eine Migration des Backends auf SQL2005Express oder den MSQL-Server den Zugriff noch zusätzlich verbessern oder bringt es nichts. Wenn ja über welche Schnittstelle sollte man ihn am besten ansprechen?

Grüße aus Bremen

Matthias

[Bei dieser Antwort wurde das Vollzitat nachträglich automatisiert entfernt]

#5

Hallo,

bzgl. der Migation eines Jet-Datenbank auf einen SQL-Server(MSSQL,Oracle,MySQL) habe ich die Erfahrung gemacht, das die Datenzugriffe nur dann schneller werden wenn die Abfragen auch auf dem Server gerechnet werden. Zugriffe von in Access definierten Abfragen, und auch Formulare koennen u.U. erheblich langsamer werden.
z.B. du verwendest in einer Abfrage 3 Tabellen die per Union verbunden sind, ewt. noch eine oder 2 Bedingungen; Access zieht dann alle Daten der Tabellen an und errechnet das Ergebiss selbst, das wird dann recht langsam, denn es werden zuerst mal alle Daten aller Tabelle durchs Netz gejagt. Erfahrungsgemaes liegt das Performanceproblem meist in der Netzkapazitaet und weniger am Server begruendet.
Ein Beispiel aus meiner Praxis: Access-Frontend mit Oracle 11i per ODBC, mehrfach Segmentiertes Netzwerk mit ca. 500 Workstations. Der Zugriff auf eine Tabelle mit ca. 20.000 Datensaetzen dauert von einer WS aus 10-25 sec, fuehrt man die Anwendung direkt auf einem der Server aus dauert die gleiche Abfrage 0,2 sec.

Definierst du dann noch die Abfragen direkt in der SQL-DB und hast eine flotten Server wird es richtig schnell.
Die besten Erfahrungen mit der Zugriffsmethode habe ich mit ADO Direktzugriffen gemacht, da man dann die meiste Arbeit mittels serverbasierten Abfragen und Stored Procedures dem Server ueberlassen kann. ODBC bietet hier bei weitem nicht so viele Moeglichkeiten.
Allerdings ist dies von der Programmierung her etwas aufwendiger und man hat dann auch noch das Problem das man sich fuer die Programierung eine eigene Umgebung schaffen muss, denn wer programmiert schon gerne in einer laufenden Produktivdatenbank rum.

Tschau
Peter

Zusatzfrage:
Würde eine Migration des Backends auf SQL2005Express oder den
MSQL-Server den Zugriff noch zusätzlich verbessern oder bringt
es nichts. Wenn ja über welche Schnittstelle sollte man ihn am
besten ansprechen?

Grüße aus Bremen

#6

Hallo Matthias,

Wir fahren derzeit noch Access97, stelle aber gerade auf 2007 um…

viel Spaß bei der Fehlersuche :smile:
Tipp: neue DB in Ac2007 anlegen und die alte importieren, nicht konvertieren!! da ihr zwei Versionen übersprungen habt!

Der Server hat 2 GB, wobei schätzungsweise 90% des
Datentraffics durch Access entstehen dürften.

die Frage ist: was macht er noch? Da nicht nur die Traffic relevant ist.

  • Anmeldeserver
  • Printserver
  • Exchangeserver
    etc. bremsen auch.

Die Einstellungen an den Frontend haben wir geprüft - ohne
Ergebnis, wobei ich mir halt nicht sicher war, ob die
Einstellung „Bearbeiteter Datensatz“ die richtige war.

-> öffnen mit Datensatzsperrungen auf jeden Fall ausschalten!
-> Aktualisierungsintervalle DDE etc. erhöhen bzw. reduzieren.

Die Abfragen im Frontend sind nicht ohne, aber genau die damit
erzeugten Infos brauchen meine Kollegen.

Abfragen kann man optimieren :smile:
Thema: Indexierung, Reihenfolge der Kriterien etc.

Wobei diese Abfragen i.d.R. an anderer Stelle oder erst nach dem Anlegen des DS gebraucht werden (z.B. in Pull-Down-Feldern oder in Berichten)

ok, bei Berichten dürfte keine Satzsperrung nötig sein
bei Pulldownfeldern auch nicht!

Fazit:
Werde mich auf jeden Fall um einen neuen Server kümmern.

gute Idee :smile:

Zusatzfrage:
Würde eine Migration des Backends auf SQL2005Express oder den
MSQL-Server den Zugriff noch zusätzlich verbessern oder bringt
es nichts.

das kommt drauf an:

  • wie viele User arbeiten mit dem System der DB?
    ab ca. 100 sinnvoll

  • wie viele Datensätze werden verwaltet?
    ab ca. 500.000 sinnvoll

  • langsame Abfragen werden auch nicht schneller mit anderen Backends abgearbeitet

Wenn ja über welche Schnittstelle sollte man ihn am besten ansprechen?

Die Auswahl ist begrenzt auf ODBC!

Grüße aus Schönberg (Lübeck)
Wolfgang
(Netwolf)