Access-Datenbank gesperrt - Problem mit Windows-Update?

[berens]

Hallo zusammen!

Ich verwende in meinem Programm TAdoConnection um auf eine Access-Datenbank zuzugreifen (.mdb-Datei).

Zitat:

Bevor ihr mich auffresst: Die Kunden können mittlerweile meine Software auch mit einem SQL-Server benutzen ( https://www.delphipraxis.net/204437-...g-welches.html ), allerdings lässt sich das nicht bei allen Kunden unmittelbar umstellen oder umsetzen, da es dort teilweise nicht gewünscht oder schlicht und einfach überdimensioniert wäre. Dementsprechend muss ich mich jetzt um die Bestandskunden(probleme) kümmern.

Ich rede jetzt im Nachfolgenden von Kunden, die seit einem Jahr kein Update meiner Software eingespielt haben, da alles einwandfrei läuft.
Seit Mai 2020 kommt es regelmäßig zu dem Problem, dass die Datenbankdatei beim Schreiben auch nur kleinster Änderungen korrumpiert wird (nachgewiesenes Windows-Update Problem). Nachdem das Verhalten mit den Windows-Updates vom August scheinbar größtenteils behoben wurde, erhalte ich von immer mehr Kunden (aktuell: 3) die Meldung über weitere Datenbankprobleme. Jedoch nicht, dass die Datenbank defekt ist, sondern dass die Software sich merkwürdig verhält. Ein Blick in die Logs offenbart folgendes:

TAdoQuery feuert beim Lesen von Werten oder beim Öffnen der Abfrage ("Select Top 1 * from") folgende Exceptions:

Code:

LoadFromDatabase.Exception: Zu viele aktive Benutzer

Code:

GetDB_Int.Exception: Die Datenbank wurde von Benutzer '' auf Computer '' in einen Status versetzt, in dem sie nicht geöffnet oder gesperrt werden kann

Anmerkung: Hier habe ich nicht aus Datenschutzgründen den Inhalt für "Benutzer" und "Computer" entfernt, die Werte sind tatsächlich leer!

Nun, die Fehlermeldungen an sich sind ja verständlich. Warum sie erscheinen, entbehrt jedoch jeglicher Grundlage.

1) Die Installation wurde seit einem Jahr nicht verändert. Die Benutzer arbeiten wegen den vorherigen Störungen aktuell "eher weniger" mit der Software, als mehr. Mit "zu viele Benutzer" meint das Programm ca... 3 Stück insgesamt? Die Zahl ist nicht höher als früher auch. Warum kommt es jetzt zu dem Problem?

2) "In einen Status versetzt" - ich nehme an, das soll heißen, sie ist Exklusiv geöffnet. Mein Programm macht das an keiner Stelle (absichtlich). Ich würde hier fast vermuten, dass z.B. Virenscanner oder Backupprogramm die Datei nach einem Schreibvorgang vor (weiteren) Änderungen schützen, bis sie komplett gesichert / gescannt wurde. Google-Suchen offenbaren viele Threads (größtenteils von vor vielen Jahren) zu dem Thema, meist auch mit den Aussagen, dass das Problem "irgendwann" auftaucht und nicht mehr weggeht. Dann wurden z.B. Backups wiederherstellt, die selben Daten eingetragen, dann trat das Problem nicht mehr auf. Das würde der Windows-Update- oder Virescanner-Theorie wiedersprechen. Die Datenbank bei den Kunden wurde schon in Access "komprimiert und repariert", ein veraltetes Backup von vor > 2 Wochen würde ich ungern einspielen müssen "nur um zu testen"...

Ist das was zu dem Thema bekannt?


Generell bin ich nun sehr verunsichert, was das Thema "Exklusiver Zugriff" angeht. Generell will ich keinerlei geschützten Zugriff auf die Daten in der Datenbank.

Verbindungsaufbau:

Delphi-Quellcode:

    db.Close;
    db.KeepConnection := HAL_Registry_GetBool('KeepConnection', True);
    db.LoginPrompt := False;
    db.ConnectionString := 'Provider=Microsoft.Jet.OLEDB.4.0;'
                       + 'Data Source=' + _FileName + ';'
                       + 'Mode=Share Deny None;'
                       + 'Persist Security Info=False;';
    db.Open;

Aus der Recherche und Forensuche habe ich herausgefunden, dass sich die TAdoConnection unter bestimmten Bedingungen selbständig in den Exklusiven Modus schaltet:
1) Änderung an der Datenbankstruktur
2) ???
In der Tat ist es richtig, dass mein Programm auch die Datenbank nach einem Update auf das aktuelle Patchlevel anhebt (hinzufügen von Spalten oder sogar ganzen Tabellen) - laut Forum springt hier die AdoConnection in den exklusiven Modus. Dies geschieht jedoch nur einmalig nach dem Update, nicht bei jedem Programmstart. Und danach wird die TAdoConnection eh getrennt und neu verbunden - das soll angeblich helfen, damit Share Deny None wieder richtig greift.

-Sind andere Situationen bekannt, in denen ich mit ADO versehentlich eine exklusive Sperre auf eine Tabelle legen könnte?
-Spielt die CursorLocation eine Rolle? Diese wird von mit aktuell nicht explizit gesetzt und verwendet den Standardwert...
-Wird die Sperre sicher damit aufgehoben, dass ich einfach nur db.close; db.open; mache, oder muss ich nochmal explizit den ConnectionString neu zuweisen oder eine andere Eigenschaft der TAdoConnection ändern?
-Wonach kann ich noch schauen?

(M)eine aktuelle Empfehlung an die Kunden lautet, meine datenbank.mdb und datenbank.ldb von der Echtzeitprüfung im Virenscanner auszunehmen und die Umstellung auf SQL priorisiert in Betracht zu ziehen.

Sonst noch eine Idee?