kitebuddy
Goto Top

Access verliert Verbindungsdatei zu SQL bei Mehrfachzugriff

Hallo Zusammen,

wir haben über Access 2010 einen Zugriff auf eine SQL 2008 Datenbank erstellt, in der einige Mitarbeiter Stammdaten pflegen sollen. Nun haben wir aber das Phänomen das nur der erste Benutzer die Access Datei nutzen kann. Der nächste Benutzer erhät die Fehlermeldung das die Datenbank nicht zur Verfügung steht. Wählt er aber die Verbindungsdatei manuell nochmals aus, geht es wieder. Vor allem auch Dauerhaft. Sobald dann der nächste Benutzer die Datei nutzen möchte, hat dieser wieder das gleiche Problem. Wieder Verbindungsdatei ausgewählt und schon geht es bei Ihm, aber dann bei dem anderen Kollegen nicht mehr. Ein Teufelskreis ;o)
Hatte jemand schon mal diesen Fehler und kann einen Tip liefern?

Da ich erst mal nicht weiß welche weiteren Informationen hier hilfreich sein können, lasse ich meine Anfrage erst mal so im Raum stehen.


Vielen Dank schon mal für eure Anregungen.
Alex

Content-Key: 197859

Url: https://administrator.de/contentid/197859

Printed on: April 19, 2024 at 06:04 o'clock

Member: Pjordorf
Pjordorf Jan 29, 2013 at 15:56:18 (UTC)
Goto Top
Hallo,

Zitat von @kitebuddy:
in der einige Mitarbeiter Stammdaten pflegen
Wo? Sollen die Daten in der Access Datenbank (brrr) oder in der MS (?) SQL 2008 datenbank geändert werden?

anderen Kollegen nicht mehr.
Front-End? Back-End? Middle-Tier?

Hatte jemand schon mal diesen Fehler und kann einen Tip liefern?
Wer sagt das die ein Fehler ist? Ich deute es nicht so.

Da ich erst mal nicht weiß welche weiteren Informationen hier hilfreich sein können
Nur unwichtiges wie:
Welches OS am Client (Ihr habt doch Clients oder?)
Wo ist die Access Datenbank abgelegt?
Wie greifen deine Clients auf die (gemeinsame) Access Datenbank drauf zu?
Ist die Access Datenbank in eine Front-End und eine Back-end (MS SQL 2008) aufgeteilt?
Wenn nur eine Access Datenbank (Datei) in einem Freigegebenen Ordner und alle benutze genau diese eine Access Datei, wie ist der Benutzerzugriff geregelt worden?
Wie wird hier mit welcher Verbindungsdatei (Extern?!?) wann was eingebunden was Anwender auswählen können?

Gruß,
Peter
Member: kitebuddy
kitebuddy Jan 30, 2013 at 07:22:49 (UTC)
Goto Top
Hi Peter,

danke für die Rückfragen, die ich dir gerne versuche zu beantworten...

Zitat von @Pjordorf:
Hallo,

> Zitat von @kitebuddy:
> in der einige Mitarbeiter Stammdaten pflegen
Wo? Sollen die Daten in der Access Datenbank (brrr) oder in der MS (?) SQL 2008 datenbank geändert werden?
Die Daten sollen in MS SQL 2008 geändert werden. Access dient nur als Front-End.


> anderen Kollegen nicht mehr.
Front-End? Back-End? Middle-Tier?
Front-End

> Hatte jemand schon mal diesen Fehler und kann einen Tip liefern?
Wer sagt das die ein Fehler ist? Ich deute es nicht so.
Da es nicht funktioniert, seh ich das erst mal als Fehler ;o)


> Da ich erst mal nicht weiß welche weiteren Informationen hier hilfreich sein können
Nur unwichtiges wie:
Welches OS am Client (Ihr habt doch Clients oder?)
Die Clients sind alle Windows 7

Wo ist die Access Datenbank abgelegt?
Das Access Fron-Edn liegt auf einem Netzwerk Share.

Wie greifen deine Clients auf die (gemeinsame) Access Datenbank drauf zu?
Über eine Netzwerkfreigabe.

Ist die Access Datenbank in eine Front-End und eine Back-end (MS SQL 2008) aufgeteilt?
Nein, die Datenbank ist komplett in MS SQL 2008

Wenn nur eine Access Datenbank (Datei) in einem Freigegebenen Ordner und alle benutze genau diese eine Access Datei, wie ist
der Benutzerzugriff geregelt worden?
Die Benutzer haben alle Schreibrechte auf die Datei.

Wie wird hier mit welcher Verbindungsdatei (Extern?!?) wann was eingebunden was Anwender auswählen können?
Falls ich dich hier richtige Verstanden habe...
In Access Datei sind enthalten: Formulare und über ODBC auf SQL verknüpfte Tabellen.


Gruß,
Peter

Danke und viele Grüße
Alex
Member: Pjordorf
Pjordorf Jan 30, 2013 at 13:32:02 (UTC)
Goto Top
Hallo,

Zitat von @kitebuddy:
Die Daten sollen in MS SQL 2008 geändert werden. Access dient nur als Front-End.
OK.

Da es nicht funktioniert, seh ich das erst mal als Fehler ;o)
Naaaa, vorsicht.face-smile

Das Access Fron-Edn liegt auf einem Netzwerk Share.
Über eine Netzwerkfreigabe.
Das bedeutet das alle Clients sich per Freigabe das gleiche Access Programm (Front-end) per LAN ziehen und verwenden. Daher oben mein "Vorsicht". Wie ist hier der Mehrbenutzerbetrieb denn geregelt wenn mehr als ein Client dieses Access Front-end nutzt? Alternativ: was passiert wenn du dieses Access Front-end auf jeden Client verteilst und von dort ausführen lässt sodass eben immer nur 1 Client mit seinem eigenen Access Front-end arbeitet (jeder hat sein eigenes). Kommt es dann immer noch zu deinen Verbindungsproblemen das sich die Clients gegenseitig rauskegeln?

Die Benutzer haben alle Schreibrechte auf die Datei.
Das hat aber nichts mit Mehrbenutzer und gleichzeitigen nutzen einer einzigen per Freigabe zur Verfügung gestellten Access Applikation (hier das Front-end) zu tun. Das sind (NTFS) Rechte auf Dateiebene.

In Access Datei sind enthalten: Formulare und über ODBC auf SQL verknüpfte Tabellen.
Es ging hier eher um die "Verbindungsdatei" die du erwähnt hast.

Auch Access kennt Sperrmechanismen um den Zugriff gleichzeitig von mehreren Benutzern und oder Rechner zu regeln damit eine Datenkonsistenz gewahrt bleibt. Wie ist das in euerer Applikation (Access Front-end) überhaupt geregelt?

Gruß,
Peter
Member: kitebuddy
kitebuddy Feb 01, 2013 at 15:16:47 (UTC)
Goto Top
Hi Peter,

das Problem ist gelöst.
Wir haben eine neue SQL Datenbank aufgesetzt und die Daten aus der ursprünglichen Access Datenbank wieder importiert.
Vorher hatten wir die Daten aus der Entwicklungs-SQL-Datenbank übernommen, dabei muss wohl irgendwas schief gelaufen sein. Jetzt klappt es jedenfalls und alle Nutzer können darauf zugreifen.

Ich danke dir vielmals für die Unterstützung!

Viele Grüße
Alex
Member: Pjordorf
Pjordorf Feb 02, 2013 at 17:02:03 (UTC)
Goto Top
Hallo,

Zitat von @kitebuddy:
das Problem ist gelöst.
Klasse.

Dann mach doch bitte noch ein How can I mark a post as solved? dran.

Gruß,
Peter