wake-up-neo.com

Einrichten einer MS-Access-DB für den Mehrbenutzerzugriff

Wir denken daran, eine kleine MS-Access-Datenbank mit ein paar Tabellen, Formularen und Abfragen für mehrere Benutzer zu "vergrößern". (Die Verwendung eines anderen Backends ist eine weitere, aber langfristigere Option, die derzeit leider nicht akzeptabel ist.)
Die meisten Benutzer sind schreibgeschützt, es gibt jedoch einige (derzeit ein oder zwei) Benutzer, die Änderungen vornehmen müssen (während die schreibgeschützten Benutzer auch die Datenbank verwenden). Wir sind nicht so sehr über die Sicherheitsaspekte besorgt, sondern über einige der folgenden Probleme:

  • Wie können wir sicherstellen, dass der schreibende Benutzer Änderungen an den Tabellendaten vornehmen kann, während andere Benutzer die Daten verwenden? Setzen die Benutzer mit Lesezugriff Sperren für Tabellen? Muss der schreibende Benutzer die Tabelle sperren? Tut Access dies für uns oder müssen wir dies explizit codieren?
  • Gibt es allgemeine Probleme mit "MS Access-Transaktionen", die wir kennen sollten?
  • Können wir Formulare, Abfragen usw. bearbeiten, während sie verwendet werden? Wie können wir "programmieren", ohne den Benutzern im Weg zu sein?
  • Welche Einstellungen in MS Access beeinflussen den Umgang mit Dingen?
  • Unser Hintergrund liegt hauptsächlich in Oracle, wo unterscheidet sich Access im Umgang mit mehreren Benutzern? Gibt es so etwas wie "Isolationsstufen" in Access?

Alle Tipps oder Hinweise auf hilfreiche Artikel wäre sehr dankbar.

24
Thorsten

Ich finde die Antworten auf diese Frage problematisch, verwirrend und unvollständig, deshalb werde ich mich bemühen, es besser zu machen.

F1: Wie können wir sicherstellen, dass der schreibende Benutzer Änderungen an den Tabellendaten vornehmen kann, während andere Benutzer die Daten verwenden? Setzen die Benutzer mit Lesezugriff Sperren für Tabellen? Muss der schreibende Benutzer die Tabelle sperren? Tut Access dies für uns oder müssen wir dies explizit codieren?

Niemand hat dies wirklich vollständig beantwortet. Die Informationen zum Setzen von Sperren in den Zugriffsoptionen haben nichts mit Lese- oder Schreibsperren zu tun. Keine Sperren im Vergleich zu allen Datensätzen im Vergleich zu bearbeiteten Datensätzen legen Sie die Standard-Datensatzsperre für WRITES fest.

  • Keine Sperren bedeutet, dass Sie die OPTIMISTISCHE Sperre verwenden. Dies bedeutet, dass Sie mehreren Benutzern erlauben, den Datensatz zu bearbeiten und sie anschließend zu informieren, wenn sich der Datensatz geändert hat, seit sie ihre eigenen Bearbeitungen gestartet haben. Optimistisches Sperren ist das, womit Sie beginnen sollten, da es keine Codierung erfordert, um es zu implementieren, und für kleine Benutzerpopulationen verursacht es kaum jemals ein Problem.

  • Alle Datensätze bedeutet, dass die gesamte Tabelle bei jedem Start einer Bearbeitung gesperrt wird.

  • Bearbeiteter Datensatz bedeutet, dass weniger Datensätze gesperrt sind. Ob es sich jedoch um einen einzelnen Datensatz oder um mehrere Datensätze handelt, hängt davon ab, ob Ihre Datenbank für die Verwendung der Sperrung auf Datensatzebene (erstmals in Jet 4 hinzugefügt) oder der Sperrung auf Seitenebene eingerichtet ist. Ehrlich gesagt, ich hätte es nie für sinnvoll gehalten, Sperren auf Rekordebene einzurichten, da optimistische Sperren die meisten Probleme lösen.

Man könnte meinen, dass Sie pessimistisches Sperren auf Datensatzebene verwenden möchten, aber Tatsache ist, dass in der überwiegenden Mehrheit der Apps zwei Benutzer fast nie denselben Datensatz bearbeiten. Natürlich könnten bestimmte Arten von Apps Ausnahmen davon sein, aber wenn ich auf eine solche App stoßen würde, würde ich wahrscheinlich versuchen, sie durch eine Neugestaltung des Schemas zu beseitigen, so dass es für zwei Benutzer sehr ungewöhnlich wäre, dasselbe zu bearbeiten Datensatz (in der Regel durch eine Art Transaktionsbearbeitung, bei der Änderungen durch Hinzufügen von Datensätzen vorgenommen werden, anstatt die vorhandenen Daten zu bearbeiten).

Nun, für Ihre eigentliche Frage, gibt es eine Reihe von Möglichkeiten, um einige Benutzer auf Nur-Lesen zu beschränken und andere Schreibrechte zu gewähren. Jet-Sicherheit auf Benutzerebene war für diesen Zweck vorgesehen und funktioniert einwandfrei, sofern es sich um "Sicherheit" für eine sinnvolle Definition des Begriffs handelt. Solange Sie einen Jet/ACE-Datenspeicher verwenden, ist die beste Sicherheit, die Sie erhalten, die von Jet ULS bereitgestellte. Es kann geknackt werden, aber Ihre Benutzer würden eine feuergefährliche Straftat begehen, indem sie sie brechen. Dies könnte also ausreichend sein.

Ich würde dazu tendieren, Jet ULS überhaupt nicht zu implementieren und stattdessen nur die Datenbearbeitungsformulare so zu erstellen, dass sie die Windows-Anmeldung des Benutzers überprüften und die Formulare schreibgeschützt oder beschreibbar machten, je nachdem, welche Benutzer welchen Zugriff erhalten sollen. Ob Sie die Gruppenmitgliedschaft in einer Datentabelle aufzeichnen oder Windows-Sicherheitsgruppen für diesen Zweck verwalten möchten, bleibt Ihnen überlassen. Sie können auch eine Jet-Arbeitsgruppendatei verwenden, um damit umzugehen, und den Schreibbenutzern eine andere Datei system.mdw zur Verfügung stellen. Die schreibgeschützten Benutzer würden sich transparent als Administrator anmelden, und die als Administrator angemeldeten Benutzer würden nur schreibgeschützten Zugriff erhalten. Die Benutzer mit Schreibzugriff melden sich unter einem anderen Benutzernamen an (transparent, in der Verknüpfung, die Sie zum Starten der App angegeben haben, ohne Kennwort). Auf diese Weise werden die Formulare als Lese- oder Schreibzugriff eingerichtet.

Wenn Sie Jet ULS verwenden, kann es sehr haarig werden, wenn Sie es richtig machen. Dabei werden alle Tabellen schreibgeschützt (oder möglicherweise auch nicht) gesperrt und anschließend RWOP-Abfragen verwendet, um den Zugriff auf die Daten zu ermöglichen. Ich habe in 14 Jahren professioneller Access-Entwicklung nur eine solche App erstellt.

Um meine Antworten auf die Teile Ihrer Frage zusammenzufassen:

Wie können wir sicherstellen, dass der schreibende Benutzer Änderungen an den Tabellendaten vornehmen kann, während andere Benutzer die Daten verwenden?

Ich würde empfehlen, dies in der Anwendung zu tun und die Formulare je nach Benutzeranmeldung zur Laufzeit schreibgeschützt oder bearbeitbar zu machen. Am einfachsten ist es, Ihre Formulare als schreibgeschützt einzurichten und beim Öffnen des Formulars für Schreibbenutzer in bearbeitbar zu ändern.

Setzen die Benutzer mit Lesezugriff Sperren für Tabellen?

Nicht im eigentlichen Sinne. Jet/ACE verfügt zwar über Lesesperren, diese dienen jedoch nur dazu, den Status für einzelne Ansichten beizubehalten und die Daten für den Benutzer zu aktualisieren. Sie sperren keine Schreiboperationen, obwohl der Overhead, sie zu verfolgen, die Dinge theoretisch verlangsamt. Es reicht nicht aus, sich Sorgen zu machen.

Muss der schreibende Benutzer die Tabelle sperren?

Der Zugriff in Kombination mit Jet/ACE erledigt dies automatisch für Sie, insbesondere wenn Sie das optimistische Sperren als Standard auswählen. Der entscheidende Punkt hierbei ist, dass Access-Apps datengebunden sind. Sobald ein Formular geladen wird, verfügt der Datensatz über eine Lesesperre. Sobald der Datensatz bearbeitet wird, wird von festgelegt, ob er für andere Benutzer schreibgeschützt ist oder nicht ob Sie optimistische oder pessimistische Sperren verwenden. Auch dies ist die Art von Dingen, die Access mit seinen Standardverhalten in gebundenen Formen für Sie erledigt. Sie machen sich darüber keine Sorgen, bis Sie auf Probleme stoßen.

Tut Access dies für uns oder müssen wir dies explizit codieren?

Grundsätzlich ist außer dem Festlegen der Bearbeitbarkeit zur Laufzeit (je nachdem, wer über Schreibzugriff verfügt) keine Codierung erforderlich, wenn Sie die optimistische Sperre verwenden. Bei der pessimistischen Sperre müssen Sie nichtcodieren, sondern müssen dies fast immer, da Sie den Benutzer nicht einfach an den Standardverhalten und -fehlern festhalten können Mitteilungen.

F2: Gibt es allgemeine Probleme mit "MS Access-Transaktionen", die wir kennen sollten?

Jet/ACE unterstützt Commit/Rollback-Transaktionen, aber mir ist nicht klar, ob Sie dies in dieser Frage meinen. Im Allgemeinen verwende ich keine Transaktionen außer zur Aufrechterhaltung der Atomizität, z. B. beim Erstellen einer Rechnung oder bei Aktualisierungen, die mehrere Tabellen betreffen. Es funktioniert so, wie Sie es erwarten, ist jedoch für die meisten Vorgänge in einer Access-Anwendung nicht unbedingt erforderlich.

Möglicherweise ist eines der Probleme hier (insbesondere im Lichte der ersten Frage), dass Sie möglicherweise nicht genau verstehen, dass Access zum Erstellen von Apps mit an die Formulare gebundenen Daten entwickelt wurde. "Transaktionen" sind ein Thema von großer Bedeutung für ungebundene und zustandslose Apps (z. B. browserbasiert), aber für datengebundene Apps geschieht das Bearbeiten und Speichern alles auf transparente Weise.

Für bestimmte Arten von Vorgängen kann dies problematisch sein, und gelegentlich empfiehlt es sich, Daten in Access mit ungebundenen Formularen zu bearbeiten. Aber das ist meiner Erfahrung nach sehr selten der Fall. Es ist nicht so, dass ich keine ungebundenen Formulare verwende - ich verwende viele davon für Dialoge und ähnliches - es ist nur so, dass meine Apps nichteditdatentabellen mit ungebundene Formen. Mit fast keinen Ausnahmen bearbeiten alle meine Apps Daten mit gebundenen Formularen.

Ungebundene Formulare lassen sich in Access relativ einfach implementieren (insbesondere, wenn Sie Ihren Bearbeitungssteuerelementen dieselben Namen wie den zugrunde liegenden Feldern geben). Wenn Sie jedoch ungebundene Datenbearbeitungsformulare verwenden, müssen Sie Access nicht unbedingt verwenden, da es sich um eine Bindung handelt alles für dich erledigt. Der Hauptnachteil einer Aufhebung der Bindung besteht darin, dass Sie alle Formularereignisse auf Datensatzebene wie OnInsert, BeforeUpdate usw. verlieren.

Q3. Können wir Formulare, Abfragen usw. bearbeiten, während sie verwendet werden? Wie können wir "programmieren", ohne den Benutzern im Weg zu sein?

Dies ist eine der Fragen, die gut angesprochen wurden. Alle Mehrbenutzer- oder replizierten Access-Apps sollten aufgeteilt werden, und die meisten Einzelbenutzer-Apps sollten dies auch tun. Das gute Design macht die Apps außerdem stabiler, da immer nur die Datentabellen von mehreren Benutzern gleichzeitig geöffnet werden.

Q4. Welche Einstellungen in MS Access beeinflussen den Umgang mit Dingen?

"Dinge?" Welche Sachen?

Q5. Unser Hintergrund liegt hauptsächlich in Oracle, wo unterscheidet sich Access im Umgang mit mehreren Benutzern? Gibt es so etwas wie "Isolationsstufen" in Access?

Ich weiß nichts spezielles über Oracle (keiner meiner Kunden könnte es sich leisten, selbst wenn sie es wollten), aber die Frage nach einem Vergleich von Access und Oracle verrät irgendwo auf der ganzen Linie ein grundlegendes Missverständnis.

Access ist ein Tool zur Anwendungsentwicklung.

Oracle ist ein Datenbankserver mit industrieller Stärke.

Äpfel und Orangen.

Jetzt wird Access natürlich mit einem Standard-Datenbankmodul ausgeliefert, das ursprünglich als Jet bezeichnet wurde und jetzt überarbeitet und in ACE umbenannt wurde. Es gibt jedoch viele Ebenen, auf denen Access, die Entwicklungsplattform, vollständig von Jet/ACE, dem Standard-Datenbankmodul, entkoppelt werden kann.

In diesem Fall haben Sie sich für die Verwendung eines Jet/ACE-Backends entschieden, das wahrscheinlich für kleine Benutzergruppen geeignet ist, dh für Benutzer unter 25 Jahren. Jet/ACE kann auch für bis zu 50 oder 100 Benutzer geeignet sein, insbesondere wenn nur ein Nur wenige der gleichzeitigen Benutzer haben Schreibrechte. Während das Limit von 255 Benutzern in Jet/ACE sowohl schreibgeschützte als auch schreibgeschützte Benutzer umfasst, bestimmt die Anzahl der schreibgeschützten Benutzer, wie viele Benutzer gleichzeitig unterstützt werden können, und in Ihrem Fall verfügen Sie über eine App mit größtenteils Lesezugriff -nur Benutzer, daher sollte es nicht schrecklich schwierig sein, eine gute App zu entwickeln, die keine Probleme mit dem Back-End hat.

Grundsätzlich glaube ich, dass Ihr Oracle-Hintergrund wahrscheinlich zu Missverständnissen bei der Entwicklung in Access führt, bei denen der erwartete Ansatz darin besteht, Ihre Formulare an Datensatzquellen zu binden, die aktualisiert werden, ohne dass Code geschrieben werden muss. Aus Gründen der Effizienz empfiehlt es sich, Ihre Formulare nicht an ganze Tabellen, sondern an Teilmengen von Datensätzen zu binden. Selbst wenn sich eine ganze Tabelle in der Datensatzquelle hinter einem Datenbearbeitungsformular befindet, ist Access für die Bearbeitung von Jet-/ACE-Tabellen (der alte Mythos, der besagt, dass der gesamte Tisch über die Leitung gezogen werden soll), solange Ihre Datentabellen effizient indiziert werden.

Das Sperren von Datensätzen ist etwas, worüber Sie sich meistens keine Sorgen machen sollten, und einer der Gründe dafür liegt in der gebundenen Bearbeitung, bei der das Formular zu jeder Zeit weiß, was im Backend vor sich geht (naja, in Abständen über a Sekunde auseinander, das Standard-Aktualisierungsintervall). Das heißt, es ist nicht wie eine Webseite, auf der Sie eine Kopie der Daten abrufen und dann Ihre Änderungen in einer Transaktion, die nicht mit dem ursprünglichen Datenabrufvorgang verbunden ist, auf den Server zurückschreiben. In einer gebundenen Umgebung wie Access verfolgt die Sperrdatei in der Back-End-Datendatei immer die Tatsache, dass jemand den Datensatz zum Bearbeiten geöffnet hat. Auf diese Weise wird verhindert, dass die Änderungen eines Benutzers die Änderungen eines anderen Benutzers betreffen, da Access den Status kennt und den Benutzer darüber informiert. Dies alles geschieht ohne jegliche Kodierung seitens des Entwicklers und ist einer der großen Vorteile des gebundenen Bearbeitungsmodells (abgesehen davon, dass kein Code geschrieben werden muss, um die Änderungen zu veröffentlichen).

Allen erfahrenen Datenbankprogrammierern, die mit anderen Plattformen vertraut sind, die zum ersten Mal auf Access zugreifen, empfehle ich nachdrücklich, Access wie einen Endbenutzer zu verwenden. Probieren Sie alle Point-and-Click-Funktionen aus. Führen Sie die Formular- und Berichtsassistenten aus, und überprüfen Sie die von ihnen erzielten Ergebnisse. Ich kann nicht dafür bürgen, dass sie alle bewährte Praktiken demonstrieren, aber sie demonstrieren definitiv die Standardannahmen, die hinter der Art und Weise stehen, wie Access verwendet werden soll.

Wenn Sie feststellen, dass Sie viel Code schreiben, fehlt Ihnen wahrscheinlich der Zugriffspunkt.

51
David-W-Fenton

Das erste, was Sie tun müssen (falls noch nicht geschehen), ist, Ihre Datenbank in ein Front-End (mit allen Formularen/Berichten usw.) und ein Back-End (mit allen Daten) aufzuteilen. Die zweite Sache ist, die Versionskontrolle auf dem Frontend einzurichten.

Ich habe das in vielen meiner Datenbanken getan, indem die Benutzer eine kleine "Jumper" -Datenbank ausgeführt haben, um die Hauptdatenbank zu öffnen. Dieser Jumper macht die folgenden Dinge

• Überprüft, ob der Benutzer die Datenbank auf seinem C-Laufwerk hat

• Wenn dies nicht der Fall ist, installieren Sie sie und führen Sie sie aus

• Wenn ja, überprüfen Sie, welche Version sie haben

• Wenn die Versionsnummern nicht übereinstimmen, kopieren Sie die neueste Version

• Öffnen Sie die Datenbank

Dieser gesamte Überprüfungsprozess dauert normalerweise weniger als eine halbe Sekunde. Mit diesem Modell können Sie Ihre gesamte Entwicklung in einer separaten Datenbank durchführen. Wenn Sie dann bereit sind, das neue MDE freizugeben, stellen Sie es einfach auf die Netzwerkfreigabe. Wenn der Benutzer das nächste Mal den Jumper öffnet, wird die neueste Version kopiert.

In der Mehrbenutzerdatenbank gibt es auch andere Dinge, über die man nachdenken muss. Es kann sich lohnen, nach den häufigsten Fehlern zu suchen, z. B. ein Formular an eine ganze Tabelle zu binden

4
Kevin Ross

Das Sperren von Tabellen oder Datensätzen ist in Access während des Schreibens von Daten verfügbar. Sie können das Sperren von Standarddatensätzen über Extras | steuern Optionen | Registerkarte "Erweitert":

  1. Keine Schlösser
  2. Alle Datensätze
  3. Bearbeiteter Datensatz

Sie können dies in den Datensatzsperren eines Formulars oder in Ihrem DAO/ADO-Code für bestimmte Anforderungen festlegen.

Transaktionen sollten kein Problem sein, wenn Sie sie richtig verwenden.

Bewährte Methode: Trennen Sie Ihre Tabellen von all Ihrem anderen Code. Geben Sie jedem Benutzer eine eigene Kopie der Codedatei und geben Sie die Datendatei dann auf einem Netzwerkserver frei. Bearbeiten Sie eine Testkopie des Codes (und einen Link zu einer Testdatendatei) und aktualisieren Sie dann die einzelnen Codedateien des Benutzers separat. Wenn Sie Änderungen an der Datendatei vornehmen müssen (Tabellen, Spalten usw. hinzufügen), müssen alle Benutzer die Anwendung verlassen, um die Änderungen vorzunehmen.

Weitere Antworten zum Oracle-Vergleich.

2
JeffO

ich denke, Access ist die beste Wahl für Ihren Fall. Aber Sie müssen die Datenbank aufteilen, siehe: http://accessblog.net/2005/07/how-to-split-database-into-be-and-fe.html

• Wie können wir sicherstellen, dass der schreibende Benutzer Änderungen an den Tabellendaten vornehmen kann, während andere Benutzer die Daten verwenden? Setzen die Benutzer mit Lesezugriff Sperren für Tabellen? Muss der schreibende Benutzer die Tabelle sperren? Tut Access dies für uns oder müssen wir dies explizit codieren?

es gibt keine Lesesperren, es sei denn, Sie geben sie explizit an. Benutze einfach "No Locks"

• Gibt es allgemeine Probleme mit "MS Access-Transaktionen", die wir kennen sollten?

sollte keine probleme mit 1-2 schreibbenutzern geben

• Können wir Formulare, Abfragen usw. bearbeiten, während sie verwendet werden? Wie können wir "programmieren", ohne den Benutzern im Weg zu sein?

wenn Sie die Datenbank aufteilen, ist es kein Problem, mit FE-Design zu arbeiten.

• Welche Einstellungen in MS Access beeinflussen den Umgang mit Dingen?

Was meinen Sie?

• Unser Hintergrund liegt hauptsächlich in Oracle, wo unterscheidet sich Access im Umgang mit mehreren Benutzern? Gibt es so etwas wie "Isolationsstufen" in Access?

keine Isolationsstufen beim Zugriff. Übrigens können Sie später Daten nach Oracle verschieben und das Frontend für den Zugriff beibehalten, wenn Sie viele Benutzer und eine große Datenbank haben.

2
Alex Dybenko

Access ist eine großartige Datenbank für mehrere Benutzer. Es verfügt über zahlreiche integrierte Funktionen, um die Mehrbenutzersituation zu bewältigen. In der Tat ist es so sehr beliebt, weil es eine so große Mehrbenutzer-Datenbank ist. Es gibt eine Obergrenze für die Anzahl der Benutzer, die die Datenbank gleichzeitig verwenden können, um Aktualisierungen und Bearbeitungen vorzunehmen - je nachdem, wie gut der Entwickler über den Zugriff informiert ist und wie die Datenbank konzipiert wurde - und zwar zwischen 20 und ca. 50 Benutzern. Einige Zugriffsdatenbanken können für bis zu 50 gleichzeitige Benutzer erstellt werden, während andere für 20 oder 25 gleichzeitige Benutzer, die die Datenbank aktualisieren, geeignet sind. Diese Zahlen wurden für Datenbanken ermittelt, die seit mehreren Jahren in Gebrauch sind und in den Access-Newsgroups häufig diskutiert wurden.

0

Die richtige Methode zum Erstellen von Client/Server-Microsoft Access-Anwendungen, in denen die Daten in einem RDBMS gespeichert sind, ist die Verwendung der Linked Table-Methode. Auf diese Weise wird sichergestellt, dass die Datenisolierung und die Parallelität zwischen der Microsoft Access-Clientanwendung und den RDBMS-Daten ohne zusätzliche und unnötige Programmierlogik und Code aufrechterhalten werden, was die Wartung erschwert und die Entwicklungszeit verlängert.

siehe: http://claysql.blogspot.com/2014/08/normal-0-false-false-false-en-us-x-none.html

0
Clay

Ich habe das in Vista eingeführte SMB2-Protokoll gefunden, um die Zugriffsdatenbanken zu sperren. Es kann durch das folgende regedit deaktiviert werden:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\LanmanServer\Parameters] "Smb2" = dword: 00000000

0
Stephen Batich