Neuigkeiten:

Wenn ihr euch für eine gute Antwort bedanken möchtet, im entsprechenden Posting einfach den Knopf "sag Danke" drücken!

Mobiles Hauptmenü

Access Datenbank am Terminalserver korrupt.

Begonnen von Ray64, Mai 02, 2024, 10:56:09

⏪ vorheriges - nächstes ⏩

Ray64

Hallo,
zuerst vielen dank für diese Super Forum. Ich programmiere seit über 20 jahren unter anderem für access und komme aus Wien.

Trotz meine langjährige Erfahrung stehe vor folgendem Problem und komme nicht weiter:

Ein Kunde hat kürzlich auf Microsoft Server und Remotedesktop-Clients umgestellt. Die Server sind zentralisiert, und wir nutzen MS-Access 2016/2019 mit einer ACCDB Backend-Datenbank auf dem Server. Jeder Benutzer hat sein eigenes Frontend in seinem Home-Verzeichnis auf dem Server.

Nun tritt das Problem auf, dass die Backend Datenbank fast täglich am Morgen, etwa 30 Minuten nach Arbeitsbeginn, obwohl bereits gearbeitet wurde korrupt wird. Dies wiederholt sich mehrmals am Morgen. Zudem reicht nicht nur eine Reparatur sondern müssen wir regelmäßig Datensätze löschen, da sie unlesbar sind. An einem Standort verschwinden sogar Daten, die am Vortag mittags erstellt wurden und abends noch vorhanden waren (sicherung vorhanden). Andere Daten, die danach geändert wurden, bleiben jedoch erhalten!

Schließlich habe ich herausgefunden, dass die Datenbank nur dann korrupt wird, wenn Benutzer die Software beenden + sich abmelden während andere weiterarbeiten. Zum Beispiel startet Benutzer 1 das Frontend um 7 Uhr, Benutzer 2 um 8 Uhr. Benutzer 1 meldet sich um 16 Uhr ab, während Benutzer 2 bis 18 Uhr weiterarbeitet. Dann wird die Datenbank garantiert am gleichen tag spätestens am nächsten Tag, aber nicht unmittelbar am Morgen, sondern erst nach etwa 30 Minuten Arbeitszeit, korrupt.

Fast immer werden Datensätze korrupt vom Vortag, die aber in der Sicherung am Abend noch vorhanden und gut sind.

ein krasses Beispiel:
Kunde ruft in der Früh an, Datenbank Korrupt.
ich repariere und dabei sind alle 7 Patienten die man am vorherigen tag seit mittags angelegt hat korrupt. aber nicht die dazugehörige Termine!!!! wie geht das bitte? natürlich sind dann die Termine auch nicht mehr brauchbar weil die Beziehungen nicht mehr passen.

Es sieht danach aus als ob, wenn der erste Benutzer vom Tag sich abmeldet und andere weiterarbeiten, Daten im Cache verbleiben, die nicht synchronisiert sind mit dem, was gespeichert ist.

Ich habe alle gebeten, sich nicht aus der Anwendung abzumelden, sondern sie einfach laufen zu lassen und die Sitzung mit "X" zu beenden. Wenn die Benutzer meine Anweisung folgen, bleibt die Datenbank intakt.

Jedoch ist das keine saubere Lösung für das Problem. Hat jemand eine Idee dazu?

zur info: 1. Die Applikation funktionierte am normal server und lokale PCs Jahre lang problemlos. erst bei der Umstellung auf terminal Clients sind diese Probleme aufgetaucht.
2. Alle standard Lösungen die man so im google findet bei corrupt database habe ich schon geprüft.

Ich bin dankbar für jeden Hinweis.

lg,
R.

ebs17

Gibt es Backup-Prozesse, die zur Arbeitszeit oder mit einer Abmeldung und also parallel zum aktiven Zugriff auf das Backend ausgelöst werden?
Mit freundlichem Glück Auf!

Eberhard

Ray64

Nein. keine besondere backups und sonst auch keine automatische ablaufe die bei der Abmeldung stattfinden bzw. nichts was uns als verdächtig aufgefallen wäre.
Es gibt schon server Sicherungen, die laufen aber den ganzen tag durch, glaub halbstündlich


Ray64

von microsoft gibt es eine Lösung bei Korrupte access databases was mal vor jahren nach einem windows update aufgetaucht ist. da musste man den lease am pc wo das backend gehostet ist disabeln.

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\lanmanserver\parameters /v DisableLeasing /t REG_DWORD /d 1 /f

das haben wir ausprobiert und es hat "vielleicht" das problem gelöst.

ich schreibe "vielleicht" weil wir das nicht länger als 2 tage haben laufen lassen können. Weil die Applikation und auch andere apps waren danach wirklich extrem und unzumutbar langsam, es war absolut unmöglich damit zu arbeiten.

deshalb bin ich mir ziemlich sicher dass es irgendwie und irgendwo am cache liegt, und das betrifft auch nur der erste der die Datei aufmacht und dann irgendwann schließt.