Problem mit Access-Datenbanken vom Netzwerk und dem Bildschirmschoner
Hallo,
ich kenne das Problem schon ewig, aber nun nervt es doch.
Wir haben hier eine Access-DB aus historischen Gründen.
Es ist Access (2016) und es funktioniert prima.
Das Front-End ist auf den PCs (Win 10 Pro 1809 und 1903) und das Backend auf einer Freigabe eines Servers (Server 2016).
Es war schon immer so (ich glaub schon zu win7 Zeiten), dass man keine Stromsparmodi verwenden konnte solange die DB läuft.
Klar, wenn das Netzwerk weg ist, ist auch die DB weg.
Aber auch wenn man nur den Stromsparmodus für den Bildschirm aktiviert, stürzt die DB nach meiner Rückkehr sofort ab.
Ein Ping welcher die ganze Zeit läuft zeigt keine Probleme. Auch die Netzwerklaufwerke sind da.
Es tritt auch bei allen PCs (verschiedene Hersteller) auf und tritt auch mit einer leeren Access-DB auf.
Für mich war das immer ein Access-Bug.
Aber vieleicht hat ja Jemand eine Idee.
Danke
Stefan
ich kenne das Problem schon ewig, aber nun nervt es doch.
Wir haben hier eine Access-DB aus historischen Gründen.
Es ist Access (2016) und es funktioniert prima.
Das Front-End ist auf den PCs (Win 10 Pro 1809 und 1903) und das Backend auf einer Freigabe eines Servers (Server 2016).
Es war schon immer so (ich glaub schon zu win7 Zeiten), dass man keine Stromsparmodi verwenden konnte solange die DB läuft.
Klar, wenn das Netzwerk weg ist, ist auch die DB weg.
Aber auch wenn man nur den Stromsparmodus für den Bildschirm aktiviert, stürzt die DB nach meiner Rückkehr sofort ab.
Ein Ping welcher die ganze Zeit läuft zeigt keine Probleme. Auch die Netzwerklaufwerke sind da.
Es tritt auch bei allen PCs (verschiedene Hersteller) auf und tritt auch mit einer leeren Access-DB auf.
Für mich war das immer ein Access-Bug.
Aber vieleicht hat ja Jemand eine Idee.
Danke
Stefan
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 465662
Url: https://administrator.de/forum/problem-mit-access-datenbanken-vom-netzwerk-und-dem-bildschirmschoner-465662.html
Ausgedruckt am: 02.04.2025 um 09:04 Uhr
10 Kommentare
Neuester Kommentar
Moin,
wir haben hier ebenfalls noch eine ganze Reihe von Access DBs in Benutzung und trotz aktivem Energiesparmodus keine Probleme mit abstürzenden Datenbanken.
Klar ist Access nicht so prickelnd und ich würde das eher heute als morgen rausschmeißen, aber "das haben wir ja schon so lange und denken Sie mal an die ganzen Benutzer, die müssen sich dann umgewöhnen" Aussagen reichen mir
Gruss
wir haben hier ebenfalls noch eine ganze Reihe von Access DBs in Benutzung und trotz aktivem Energiesparmodus keine Probleme mit abstürzenden Datenbanken.
Klar ist Access nicht so prickelnd und ich würde das eher heute als morgen rausschmeißen, aber "das haben wir ja schon so lange und denken Sie mal an die ganzen Benutzer, die müssen sich dann umgewöhnen" Aussagen reichen mir
Gruss
Zitat von @SlainteMhath:
das Access auf einem SMB Share (auch nur das Backend) wird von MS eigentlich nicht supported.
das Access auf einem SMB Share (auch nur das Backend) wird von MS eigentlich nicht supported.
Moin,
hast Du hierfür eine Quelle?
Gruss
Hallo,
Access ist ein DESKTOP-Datenbank-Management-System und setzt vom Grundkonzept her auf eine lokale DB. Das Front-End und die DB-Engine befinden sich auf dem selben Rechner. Bei jeder Funktion der DB-Engine muß diese die vollständige DB laden und bearbeiten. Deshalb soll die DB auf einem lokalen Datenträger liegen.
Bei einem Client-Server-DB-Management-System liegen Front-End (Client) und DB-Engine (Server) auf unterschiedlichen Rechnern. Aber auch hier ist die DB lokal auf dem Rechner, auf dem die DB-Engine läuft.
Eine Access-DB auf einem SMB-Share (was für den PCja wie ein lokales Laufwerk wirkt), ist von M$ nicht verboten. Aber es wird dringend davon abgeraten.
Ja, weil sie lokal liegen soll, soll man sie ja "mitnehmen"!
Jürgen
PS: Hier noch ein interessanter Link:
https://support.office.com/de-de/article/M%C3%B6glichkeiten-der-Freigabe ...
Access ist ein DESKTOP-Datenbank-Management-System und setzt vom Grundkonzept her auf eine lokale DB. Das Front-End und die DB-Engine befinden sich auf dem selben Rechner. Bei jeder Funktion der DB-Engine muß diese die vollständige DB laden und bearbeiten. Deshalb soll die DB auf einem lokalen Datenträger liegen.
Bei einem Client-Server-DB-Management-System liegen Front-End (Client) und DB-Engine (Server) auf unterschiedlichen Rechnern. Aber auch hier ist die DB lokal auf dem Rechner, auf dem die DB-Engine läuft.
Eine Access-DB auf einem SMB-Share (was für den PCja wie ein lokales Laufwerk wirkt), ist von M$ nicht verboten. Aber es wird dringend davon abgeraten.
Und eine MDB-Datei ist so schön portabel.
Ja, weil sie lokal liegen soll, soll man sie ja "mitnehmen"!
Jürgen
PS: Hier noch ein interessanter Link:
https://support.office.com/de-de/article/M%C3%B6glichkeiten-der-Freigabe ...
Zitat von @chiefteddy:
Eine Access-DB auf einem SMB-Share (was für den PCja wie ein lokales Laufwerk wirkt), ist von M$ nicht verboten. Aber es wird dringend davon abgeraten.
Eine Access-DB auf einem SMB-Share (was für den PCja wie ein lokales Laufwerk wirkt), ist von M$ nicht verboten. Aber es wird dringend davon abgeraten.
Moin,
auch hier die Frage nach der direkten MS Quelle für diese Aussage.
Gruss
Zitat von @SlainteMhath:
Tatsächlich scheint das mit neueren Versionen nun offiziell unterstützt zu werden. Früher(TM) war das bei MS verpönt
Tatsächlich scheint das mit neueren Versionen nun offiziell unterstützt zu werden. Früher(TM) war das bei MS verpönt
Hallo,
eine direkte Quelle habe ich auch nicht, dazu ist diese Erkenntnis schon zu alt. Die Sinnhaftigkeit dieser Aussage ergibt sich aber aus der Funktionsweise, auch wenn es in der aktuellen Version nicht mir ganz so konsequent gesehen wird.
Die DB-Engine, die alle Manipulationen an der DB durchführt, muß bei jeder Aktion die vollständige DB im Zugriff haben.
Bei einer Client-Server-Struktur (zB. MS SQL) schickt der Client die "Aufgabe" an den Server und die dort laufende DB-Engine führt die "Aufgabe" aus (in der lokal auf dem Server liegenden DB) und schickt nur das Ergebnis über das Netzwerk an den Client. Dh., die DB verläßt niemals den Server, nur Frage und Antwort werden über das Netzwerk transportiert.
Bei einem lokalen DB-System (zB. MS Access) sind Client und DB-Engine auf einen Rechner. Auch hier übergibt das Front-End (Client) die "Aufgabe" an die DB-Engine (allerdings intern). Die DB-Engine lädt nun die DB in den RAM und führt die "Aufgabe" aus (so wie es in der Client-Server-Struktur auf den DB-Server auch geschieht). Je nach Größe der DB und dem vorhandenem Arbeitsspeicher erfolgt das Laden und Bearbeiten der DB in mehereren Schritten. Wenn die DB nun nicht lokal sondern auf einem Netzwerkshare liegt, geht der gesamte Datenverkehr zum laden und cachen der DB über das Netzwerk (mit der entsprechenden Performace). Und wenn die DB länger nicht genutzt wurde, fliegt sie aus dem Arbeitsspeicher des PCs. Bei einem erneuten Zugriff muß sie wieder über das Netzwerk geladen werden. Je größer die DB, umso "lahmarschiger" wird das System.
Deshalb wird in
https://support.office.com/de-de/article/M%C3%B6glichkeiten-der-Freigabe ...
ja auch empfohlen, die DB in ihre Komponenten aufzuteilen und einen Teil davon lokal auf dem PC zu speichern.
"Freigeben einer geteilten Datenbank
Diese Methode ist besonders geeignet, wenn weder eine SharePoint-Site noch ein Datenbankserver vorhanden ist. Sie können freigegebene geteilte Datenbanken über ein Netzwerk oder eine SharePoint-Site nutzen. Beim Aufteilen einer Datenbank organisieren Sie diese in zwei Dateien neu: einer Back-End-Datenbank, die die Datentabellen enthält, und einer Front-End-Datenbank, die alle anderen Datenbankobjekte enthält, z. B. Abfragen, Formulare und Berichte. Jeder Benutzer interagiert mit den Daten mittels einer lokalen Kopie der Front-End-Datenbank."
Von den Problemen beim gleichzeitigen Zugriff meherer User auf die DB (Stichwort: DB-Konsistenz; Sperre des gerade bearbeiteten Daten-Feldes, -Satzes oder der DB) will ich jetzt gar nicht reden.
Zusammengefaßt: MS-Access ist ein DB-System zur lokalen Nutzung durch einen User. Wenn man eine DB für mehere User im Netzwerk bereitstellen will, nutzt man eine Client-Server-Architektur (zB. MS SQL). Dabei kann Access als Front-End auf dem Client dienen. Somit kann man den Komfort der GUI-Entwicklung und -Nutzung von Access mit der Stabilität und Perfornance eines DB-Servers kombinieren.
Jürgen
eine direkte Quelle habe ich auch nicht, dazu ist diese Erkenntnis schon zu alt. Die Sinnhaftigkeit dieser Aussage ergibt sich aber aus der Funktionsweise, auch wenn es in der aktuellen Version nicht mir ganz so konsequent gesehen wird.
Die DB-Engine, die alle Manipulationen an der DB durchführt, muß bei jeder Aktion die vollständige DB im Zugriff haben.
Bei einer Client-Server-Struktur (zB. MS SQL) schickt der Client die "Aufgabe" an den Server und die dort laufende DB-Engine führt die "Aufgabe" aus (in der lokal auf dem Server liegenden DB) und schickt nur das Ergebnis über das Netzwerk an den Client. Dh., die DB verläßt niemals den Server, nur Frage und Antwort werden über das Netzwerk transportiert.
Bei einem lokalen DB-System (zB. MS Access) sind Client und DB-Engine auf einen Rechner. Auch hier übergibt das Front-End (Client) die "Aufgabe" an die DB-Engine (allerdings intern). Die DB-Engine lädt nun die DB in den RAM und führt die "Aufgabe" aus (so wie es in der Client-Server-Struktur auf den DB-Server auch geschieht). Je nach Größe der DB und dem vorhandenem Arbeitsspeicher erfolgt das Laden und Bearbeiten der DB in mehereren Schritten. Wenn die DB nun nicht lokal sondern auf einem Netzwerkshare liegt, geht der gesamte Datenverkehr zum laden und cachen der DB über das Netzwerk (mit der entsprechenden Performace). Und wenn die DB länger nicht genutzt wurde, fliegt sie aus dem Arbeitsspeicher des PCs. Bei einem erneuten Zugriff muß sie wieder über das Netzwerk geladen werden. Je größer die DB, umso "lahmarschiger" wird das System.
Deshalb wird in
https://support.office.com/de-de/article/M%C3%B6glichkeiten-der-Freigabe ...
ja auch empfohlen, die DB in ihre Komponenten aufzuteilen und einen Teil davon lokal auf dem PC zu speichern.
"Freigeben einer geteilten Datenbank
Diese Methode ist besonders geeignet, wenn weder eine SharePoint-Site noch ein Datenbankserver vorhanden ist. Sie können freigegebene geteilte Datenbanken über ein Netzwerk oder eine SharePoint-Site nutzen. Beim Aufteilen einer Datenbank organisieren Sie diese in zwei Dateien neu: einer Back-End-Datenbank, die die Datentabellen enthält, und einer Front-End-Datenbank, die alle anderen Datenbankobjekte enthält, z. B. Abfragen, Formulare und Berichte. Jeder Benutzer interagiert mit den Daten mittels einer lokalen Kopie der Front-End-Datenbank."
Von den Problemen beim gleichzeitigen Zugriff meherer User auf die DB (Stichwort: DB-Konsistenz; Sperre des gerade bearbeiteten Daten-Feldes, -Satzes oder der DB) will ich jetzt gar nicht reden.
Zusammengefaßt: MS-Access ist ein DB-System zur lokalen Nutzung durch einen User. Wenn man eine DB für mehere User im Netzwerk bereitstellen will, nutzt man eine Client-Server-Architektur (zB. MS SQL). Dabei kann Access als Front-End auf dem Client dienen. Somit kann man den Komfort der GUI-Entwicklung und -Nutzung von Access mit der Stabilität und Perfornance eines DB-Servers kombinieren.
Jürgen