August 17, 2022, 15:24:52

Neuigkeiten:

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


Access-Datenverluste nach Verbindungsabbruch

Begonnen von Joachim01, Juli 28, 2022, 11:25:49

⏪ vorheriges - nächstes ⏩

Joachim01

Hallo,

mein Problem ist sicherlich nicht neu und wurde an verschiedenen Stellen bereits diskutiert. Ich versuche gerade, die schnellsten und effektivsten Lösungsmöglichkeiten zu erkennen.
Eine Access-Datenbank besteht aus einer Backend-Datei (mit den meisten Tabellen) und einer Frontend-Datei (mit einigen weiteren Tabellen sowie Abfragen, Formularen etc.). Office 365, Windows s10.
Beide Teile liegen auf Netzwerklaufwerken, jeder User verwendet jeweils eine eigene Kopie der Frontenddatei.

Nach Verbindungsabbrüchen gibt es immer mal wieder Datenverluste in den Tabellen des Backends.

Welche der folgenden Maßnahmen bringen mir den größten Nutzen?

1.) Umzug des Backends auf einen Datenbankserver (Oracle stünde zur Verfügung, eventuell auch mySQL)
    (Hättet Ihr bei freier Auswahl eine Präferenz bezüglich des Systems?)

2.) Bringt der Umzug der Frontenddateien auf die lokalen Rechner der User einen Nutzen, ggf. auch in Kombination mit dem Backend-Umzug?

3.) Ich hatte auch noch die Idee, mittels ereignisgesteuerter Datenmakros alle Inserts, Updates und Deletes mitzuprotokollieren, um zwischen gewünschten und fehlerbedingten Datenänderungen unterscheiden zu können.
Wäre diese Maßnahme in Kombination mit Punkt 1 und/oder 2 noch interessant?

Vielen Dank für Eure Hilfe

Viele Grüße

Joachim


PhilS

Zitat von: Joachim01 am Juli 28, 2022, 11:25:49Welche der folgenden Maßnahmen bringen mir den größten Nutzen?

1.) Umzug des Backends auf einen Datenbankserver (Oracle stünde zur Verfügung, eventuell auch mySQL)
    (Hättet Ihr bei freier Auswahl eine Präferenz bezüglich des Systems?)

2.) Bringt der Umzug der Frontenddateien auf die lokalen Rechner der User einen Nutzen, ggf. auch in Kombination mit dem Backend-Umzug?

3.) Ich hatte auch noch die Idee, mittels ereignisgesteuerter Datenmakros alle Inserts, Updates und Deletes mitzuprotokollieren, um zwischen gewünschten und fehlerbedingten Datenänderungen unterscheiden zu können.
Wäre diese Maßnahme in Kombination mit Punkt 1 und/oder 2 noch interessant?

Zu 1.) Die Maßnahme wird das Problem dauerhaft und nachhaltig lösen. - Aber, sei dir bewusst, dass es oft auch umfangreiche Nacharbeiten an den Anwendung bedeutet, wenn du auf ein Datenbank-Server-System umstellst.

Zu 2.) Es ist aus Performance- und Stabilitätsgründen generell zu empfehlen, dass jeder Benutzer ein eigenes Frontend auf seinem lokalen Rechner hat. - Bei deinem konkreten Problem mit dem beschädigten Backend wird das allerdings nicht weiterhelfen.

Zu 3.) Die Idee mit den Datenmakros ist in diesem Kontext komplett sinnlos. Wenn dein Backend beschädigt wird, weil die Netzwerkverbindung während einem Schreibvorgang plötzlich abreißt, dann kann man nicht davon ausgehen, dass ein Datenmakros in dieser Situation noch korrekt/erfolgreich ausgeführt wird.
Neue Videoserie: Windows API in VBA

Klassische CommandBars visuell bearbeiten: Access DevTools CommandBar Editor

Joachim01

Hallo PhilS,

Danke für die schnelle Antwort.

zu 1.) Meine Hoffnung ist, dass sich der Aufwand in erster Linie auf den Verbindungsaufbau, den Bau der Tabellen inklusive Anpassung der Datentypen sowie die Datenmigration bezieht.
Oder siehst Du weitere Probleme?

zu 2.) Dann erledige ich das gleich mit.

zu 3.) Der Aussage "komplett sinnlos" mag ich noch nicht ganz zustimmen.
Wenn ein Datensatz regulär gelöscht wird, soll das Macro seinen Primärschlüssel protokollieren, was bei Datenverlust durch technische Probleme vermutlich nicht der Fall wäre.
Genau das Scheitern des "Protokoll"-Macros soll den Indikator für den Verlust liefern: ein ehemals eingefügter Primärschlüssel würde plötzlich fehlen, obwohl er nicht gelöscht wurde.
Anmerkung:
Wenn Punkt 1.) -wie Du sagst- eine solide Lösung bringt, dann könnte ich mir aber Punkt 3.) vermutlich sparen.