hallo,
ich habe jetzt hier im forum schon oefters gelesen, dass man Access nicht als mehrbenutzer DB nehmen soll. warum nicht?? ich habe ein programm geschrieben was auf eine Access DB zugreift. dieses programm wird von ungefaehr 6-9 leuten gleichzeitig benutzt. ich habe das programm zwar in VB geschrieben, aber duerfte im endeffekt keinen unterschied machen. den einzigen nachteil den wir haben, ist dass man die DB oefters mal reparieren muss, da es sonst zu gross und extrem langsam wird, aber ansonsten laeuft es wunderbar. es sind natuerlich auch keine so grossen datenmengen:
8 tabellen mit jeweils max 450 eintraegen
aber wie gesagt ich habe "bis jetzt" (das programm laeuft ca. seit einem halben jahr) noch keine probleme gehabt.
was fuer eine db wuerdet ihr denn sonst empfehlen??
was fuer probleme hattet ihr, dass immer von access abgeraten wird??
gruss sonso

Access ist kein Mehrbenutzer-DBMS. Schon allein deswegen, weil kein zentraler Server existiert, der die Anmeldung mehrerer Nutzer überwachen könnte. Statt dessen wird es bei Access höchstens so sein, dass der erste einen halbwegs ungestörten Zugriff hat, und jeder folgende Zugriff durch Access feststellen muss: Irgend jemand anderes hat die Datei schon geöffnet, also sind meine Möglichkeiten beschränkt. Es wird also immer einen Nutzer geben, der beim Ändern der Daten vorteile hat: Der, der zuerst darauf zugegriffen hat.

Ein echter Datenbank-Server (Oracle, MS SQL-Server, Sybase, Interbase, Firebird, MySQL, PostgreSQL, ...) dagegen ist der Chef - er regelt die Anmeldung mehrerer Nutzer, überwacht deren Lese- und Schreib-Rechte, kann Regeln des gemeinsamen Zugriffes verwalten, konkurrierende Schreibzugriffe behandeln oder auflösen, und am wichtigsten: Kein Nutzer hat direkten Zugriff auf die Datenbank-Dateien! Also kann auch niemand versehentlich die Datei zerstören (z.B. löschen, überschreiben oder verschieben). In manchen Fällen (z.B. Oracle) kann die Datenbank sogar ein Dateisystem auf einer eigenen Partition sein.

Hallöchen,

ich arbeite in einem Labor, das seinen gesamte Datenverkehr mit MS Access (Office XP) abwickelt und ich muss sagen, dass sehr wohl auch Mehrbenutzer-Zugriff funktioniert. Die Datenbanken, die wir benutzen, sind teilweise sehr groß, speichern Unmengen Daten (>5000 Datensätze) seit vielen Jahren und laufen störungsfrei. Die Datenbanken sind allesamt auf unserem Zentralserver gespeichert und werden an verschiedenen Workstation-PCs von teilweise mehreren Leuten gleichzeitig bearbeitet. Keine Probleme (bis heute ). Das einzige, was passieren kann ist, dass ein oder mehrere Datensätze für einen Benutzer gesperrt wird, wenn ein anderer diesen bearbeitet. Ein akustisches Signal ertönt dann.

Liebe Grüße,

Claus.

@LigH:
die anmeldung bei der datenbank und somit auch die rechte habe ich im programm eingebaut, so dass Access im endeffekt nichts damit zu tun hat.

LigH:
Ein echter Datenbank-Server (Oracle, MS SQL-Server, Sybase, Interbase, Firebird, MySQL, PostgreSQL, ...) dagegen ist der Chef - er regelt die Anmeldung mehrerer Nutzer, überwacht deren Lese- und Schreib-Rechte, kann Regeln des gemeinsamen Zugriffes verwalten, konkurrierende Schreibzugriffe behandeln oder auflösen, und am wichtigsten: Kein Nutzer hat direkten Zugriff auf die Datenbank-Dateien! Also kann auch niemand versehentlich die Datei zerstören (z.B. löschen, überschreiben oder verschieben)...

wenn es angeblich nicht moeglich waere dies in access zu machen, warum gibt es dann die moeglichkeit benuter sowie benutzergruppen zu erstellen. funktioniert das nicht??? ich habe es ehrlich gesagt noch nicht ausprobiert.

ich habe bis jetzt noch keinen datenbank server benutzt, habe aber auch wie gesagt keine probleme mit access als mehrbenutzer DB.
kennt irgendjemand ein tutorial zu diesem thema?

gruss thomas

Sicher kann man in einer Access-DB-Datei auch mehrere Nutzer-Anmeldungen verwalten. Aber:

Gehen wir mal davon aus, dass die Access-Datei sich auf einem Netzwerkpfad befindet, der von mehreren Computern aus erreichbar ist. Dann werden die Zugriffsrechte von Nutzer a von der Jet-Engine verwaltet, die auf dem PC A ausgeführt wird, die Zugriffsrechte von Nutzer b von der Jet-Engine, die auf dem PC B ausgeführt wird, und die Zugriffsrechte von Nutzer c von der Jet-Engine, die auf dem PC C ausgeführt wird. Das bedeutet: Die Jet-Engine, die auf dem PC A läuft, erfährt nie etwas davon, dass Nutzer b und c auch auf die Datenbankdatei zugreifen. Und die Jet-Engines, die auf PC B und C laufen, bemerken nur, dass die Datenbankdatei schon im Zugriff ist, wissen aber nicht, dass es Nutzer a auf PC A war. Wer ein Backup machen will, müsste darauf warten, dass sämtliche Nutzer sich von der Datenbankdatei getrennt haben.

Ein echtes Mehrbenutzer-DBMS dagegen läuft mit einem Server-Programm auf einem eigenen Server-Rechner. Nutzer a, b und c müssen sich an dem einen Server-Programm anmelden. Damit weiß der Server immer, auf welche Tabellen und Datensätze Nutzer a, b und c wann zugreifen, wann es zu Konflikten kommt, und wenn der DBA (Datenbank-Admin) gerade ein Backup geplant hat, dann kann der Datenbankserver problemlos die Änderungsaufträge zwischenspeichern, so dass die Datenbank gesichert werden kann, ohne dass sich der Inhalt der Datenbank im Verlaufe des Backups verändert - alle Änderungen werden im Anschluss des Backups nachgetragen; oder alle Nutzer werden für diese Zeit ausgesperrt, je nach dem, was notwendig erscheint.

klingt alles recht logisch was du schreibst.
aber wieso sollte PC A z.b., wissen ob DB schon in benutzung ist oder nicht? solang ich die DB nicht exklusiv oeffne spielt es doch keine rolle. die benutzerliste (user die sich angemeldet haben) habe ich auch im programm bzw. ist eine tabelle eingebaut.
um ein backup zu machen, kopiere ich einfach die DB. falls jemand gerade einen recordset geaendert hat, dann ist "eben" im naechsten backup dabei.
meine version ist wahrscheinlich nicht elegantes, aber wie schon vorher gesagt, habe ich leider keinerlei erfahrung mit DB servern.
Ist es schwierig einen zu kreieren???
gruss thomas

sonso hat folgendes geschrieben:

...den einzigen nachteil den wir haben, ist dass man die DB oefters mal reparieren muss, da es sonst zu gross und extrem langsam wird,..

Die Antwort hast Du dir doch selber schon gegeben. Daß Access aber schon bei 450 Einträgen in die Knie geht ist mir neu.

@hanso
wo du recht hast, hast du recht..... :P
aber wie gesagt "der rest" funktioniert!

sonso hat folgendes geschrieben:

aber wieso sollte PC A z.b., wissen ob DB schon in benutzung ist oder nicht?

Na, um zu wissen, ob Datensätze verändert werden dürfen, ist es wichtig zu wissen, ob andere Nutzer von der Datenbank gleichzeitig lesen. Sonst kann es passieren, dass Nutzer B einen Datensatz lesen will, und Access liefert von vielleicht 5 Feldern zunächst Feld 1 und 2 - dann ändert Nutzer A den Datensatz, den Nutzer B gerade liest - und dann Feld 3, 4 und 5. Schon erhält Nutzer B inkonsistente Daten, weil die Inhalte von Feld 1 und 2 nicht mehr mit den Feldern 3, 4 und 5 zusammengehören.

Ein echter Datenbankserver hätte verhindert, dass ein Nutzer gemischte Daten erhält. Er hätte erst den kompletten Datensatz an Nutzer B geliefert, und solange die Änderungsanforderung von Nutzer A zwischengespeichert. Dann würde er den Datensatz erst dann komplett ändern, wenn Nutzer B den Datensatz komplett erhalten hat.

sonso hat folgendes geschrieben:

um ein backup zu machen, kopiere ich einfach die DB. falls jemand gerade einen recordset geaendert hat, dann ist "eben" im naechsten backup dabei.

Noch schlimmer!

Eine gute Datenbank ist ordentlich normalisiert. (Falls du nicht wissen solltest, was bedeutet, lass die Finger von Datenbankprogrammierung!) Es wird also höchstwahrscheinlich passieren, dass beim Anlegen neuer Datensätze häufig Einträge in mehreren Tabellen gleichzeitig geändert werden. Diese Datensätze, die sich über mehrere Tabellen erstrecken, werden über Primärschlüssel- und Fremdschlüssel-Spalten miteinander verknüpft sein.

Jetzt stell dir vor, ein Nutzer schreibt zunächst einen Datensatz in eine Tabelle - dann machst du dein Backup - und dann werden die davon abhängigen Datensätze in die restlichen Tabellen geschrieben. Die Datenbank geht kaputt. Du stellst sie von der letzten Kopie wieder her. Ergebnis: Du hast in einer Tabelle einen Datensatz, zu dem in den anderen Tabellen keinerlei abhängige Datensätze gehören. Das war's dann mit der Datenkonsistenz...

... Eine gute Datenbank ist ordentlich normalisiert. (Falls du nicht wissen solltest, was bedeutet, lass die Finger von Datenbankprogrammierung!)

nobody is perfect! und schliesslich kann man ja immernoch dazu lernen.
wie schon mal vorher gefragt, kennt jemand ein tutorial zu diesem thema?
gruss sonso