Office: (Office 2010) Datenbank wird zerstört

Hallo Klaus,

ist immer gut, wenn man jemanden kennt der schon mal ein ähnliches Problem
hatte und es dann auch noch erfolgreich behoben hat.

Ich habe es in mehreren Dekaden nur einmal erlebt, das ein BE defekt war.
Dabei ist die Anwendung, das Frontend, beim Zugriff komplett abgestürzt.

Daher fragte ich nochmals nach. Denn dass beim Start oder beim Arbeiten
mit dem Frontend dieses "meldet", dass sein BE repariert werden müsse,
kenne ich nicht (und kann es mir immer noch schwer vorstellen).

Ich wünsche dir jedenfalls, dass du die Lösung gefunden hast.

 

... bei bestehenden weiteren Tabellenzugriffen oder gar laufenden Schreibzugriffen (selber oder weiterer User) würde ich als ungeschickt bezeichnen. Soilches kann durchaus zwanzig Jahre möglich sein, aber erst seit kurzer Zeit praktisch vorkommen.

Ich spreche Sachverhalte an, keine Personen. Aber natürlich können und sollten Personen eigenverursachte kritische Sachzustände auch in persönliche Verantwortung nehmen.

Und der ließe sich aus Deiner vollständigen Beschreibung ableiten?
Was zeigt Deine Umsetzung?

 

Warum läuft denn diese Anwendung aber bis heute bei ca. 30 Installationen fehlerfrei?
Es wird nicht zur Laufzeit kopiert oder komprimiert (hatte ich auch nicht beschrieben)
Man muss mich nicht belehren, ob ich dies nicht als Verantwortung sehe. Ich suche die Fehler natürlich in allen Bereichen, denn ich mache das nicht erst seit heute.
Den Tipp mit den UNC Pfaden habe ci noch nicht umgesetzt.
Ideen habe ich bis jetzt in diesem Forum noch nicht gesehen.

 

Nachtrag_
in diversen Quellen wird immer auf einen Netzwerkfehler hingewiesen. Das Ereignisprotokoll meldete gestern 3 mal DNS Fehler und 3 mal ist die DB abgeschmiert.
Ich habe sogar Anwendungen da läuft es im Peer - to Peernetz unter Win7 bzw Win10 und das fehlerfrei.
Gruß

Klaus

 

Ja ne, schon klar *wink.gif*
Permanenten Zugriff auf eine BE-Tabelle um Verbindungsabbrüchen auf die Spur zu kommen,
Neue DB und Import um bei Importfehler korrupten Daten auf die Spur zu kommen ...

JMTC
Wer sein Problem einsilbig beschreibt, darf keine Wunder erwarten.

Wenn's denn nur drei von 30 Installationen betrifft, darf man IMHO auch Aussagen
bzgl. der jeweiligen Nutzerzahl, Netzwerkinfrastruktur, Zugriffsarten (lesend, schreibend) ... erwarten.

"Mein Auto fährt nicht mehr, woran liegt es"? Wünsche gutes Gelingen.

 

einsilbig ????
wer lesen kann ist im Vorteil,
Sorry, aber dieser Stil ist arrogant und zeigt, dass außer Fragen keine Hilfe zu erwarten ist.
Es ist doch egal, ob 3 oder 5 User auf die DB zugreifen. Alles andere habe ich beschrieben.
Frohes Gelingen zu wünschen ist ein Witz und zeugt nicht von der Bereitschaft sich mit einem Problem zu befassen, aber Diskussionen auslösen. Das machen nur Oberlehrer!!!!!

 

OT
Ich nehme an, du stehst zur Zeit arg unter Stress.
Gutes Gelingen zu wünschen ist durchweg ein positiv besetzter Audruck, mit der
ehrlichen Hoffnung, dass du schnell eine Lösung für dein Problem findest.
Anders nur zu deuten , wenn du dem Verfasser Sarkasmus, Zynismus oder ähnliche
Anmutungen unterstellst.
Zugleich signalisiert es meine Verabschiedung aus diesem Thema.
cu

 

Hallo Klaus,

ich habe den Thread hier mit Interesse verfolgt und bin erstaunt, wie der eskaliert ist. Die Leute die Du als arogant bezeichnest haben hier sehr vielen anderen schon geholfen. Mir im übrigen auch und die Nachfragen die sie gestellt haben sind in Ordnung.
Was mich noch interessieren würde ist die Größe der DB.
Wie schreibst Du Daten ins BE. Mit SQL Statements oder Recordsets oder rein nur über Formulare. Hatte da letztens nämlich auch eine Sternstunde mit nicht komplett referenzierten Anweisungen oder einem Barcode der nicht mehr lief unter Windows 10. Der lief vorher auch 10 Jahre *Smilie
War vor kurzem eine Umstellung auf Win10 oder läuft das schon länger?

Wenn Du Dir diese ganzen Probleme sparen willst, dann nutze ein SQL Backend. SQL Server (Express oder wie das gerade heißt) oder MySQL oder Postgrees oder....... (Hatte Jan auch schon erwähnt).

Vielleicht hat Dir ja der Tipp Deines Kollegens schon geholfen. Wenn ja, dann wäre es nett wenn Du es uns wissen lässt.

Viele Grüße
trekking

 

Lässt sich denn die DB dann gar nicht mehr öffnen? Hast Du ansonsten mal rein
geschaut und versucht den Übeltäter zu finden? Oft ist es ja nur ein DS der
abgeschossen wurde. Falls dem so ist und du ihn findest, kannst du den
zu Grunde liegenden Ursachen besser auf die Spur kommen.

Access ist nur im optimistischen Sinne mehrplatzfähig. Wenn zwei User denselben
DS gleichzeitig bearbeiten, wird der fast immer abgeschossen.

Sperrbildschirm mit Offline-Modus?

 

Zuvor hast du noch so getan als gäbe es keine Netzwerkprobleme.

Die Frage ist nun, wo der Zusammenhang zwischen Mapping/UNC und dem "zerstören" des Files liegen könnte?

Warum hat es denn bis heute ohne UNC funktioniert?

Natürlich klammert man sich an jeden Strohhalm, auch ohne es ausprobiert zu haben.

Das Problem besagt, ja dass das File nicht gefunden wird und eine Aktion deshalb nicht stattfinden kann. Vielleicht gibt es ja ein Protokoll das Rückschlüsse erlaubt, was in der Folge geschehen ist - sofern das Protokoll nicht in das Backend geschrieben wird. *grins

Die Erfahrung hat gezeigt, dass es beim Trennen vom Backend und sofortigen wieder Verbinden in wenigen Fällen zu Fehlern kommen kann. Eine Permanente Verbindung löst solche Probleme. Du hast den Vorschlag zwar vernommen, erklärst aber etwas anderes als Lösung, ohne auch nur einen Vorschlag zu testen. *boah

Problematisch ist auch ein Abschmieren während einer offenen Transaktion.
Das habe ich einmal bei einem Test geschafft und war gar nicht lustig.

Was mich interessiert: Wenn ihr für Kunden arbeitet, warum verwendet ihr dann überhaupt Access Backends in Netzwerken? Da hat Access ja seine größten Schwächen.

LG Markus

 

In der Regel kriegt einer eine Fehlermeldung.
Was meinst du damit konkret?

Edit:
Abgesehen davon ist es sehr schwer einen DS in der selben Millisekunde zu aktualisieren.
Viel öfter kommt es vor, dass ein DS seit dem Beginn der Bearbeitung im Formular durch einen anderen User geändert wurde - aber auch da kommt es zu einer entsprechenden Aktion.

 

>In der Regel kriegt einer eine Fehlermeldung.

Mit der Frage, ob speichern oder abbrechen.
Wenn man dann auf speicher klickt,
ist meiner Beobachtung nach
meistens der DS futsch.

 

Ich fasse zusammen:

Als Fakten liegen vor

• Nur bei 3 Benutzern ist ein Absturz festzustellen.
• Das Problem besteht seit ~ 14 Tagen.
• Es wird Access 2010 bis 2016 (als Vollversion oder Runtime?) eingesetzt!!!
• Die Anwender benutzen ein lokales Frontend.
• Die Netzwerkverbindung wird als Ursache ausgeschlossen.

Da hier keiner Deine Szenerie nachstellen kann, musst Du selbst Nachforschungen betreiben.

• Tritt das Phänomen nur beim Schreiben von Daten auf? Wenn ja, lässt sich dabei ein Muster ausmachen (durch ein bestimmtes Formular, durch eine Aktionsabfrage)? Ggf. lohnt es sich, temporär lokale Logs in den Frontends schreiben zu lassen, um eine Analyse weiter treiben zu können.
• Unterscheiden sich Windows- und Office-Updates auf den 3 Rechnern von den nicht betroffenen Rechnern?
• Welche Access-Versionen sind von den drei erwähnten Versionen betroffen?
• Wird mit den gleichen Spracheinstellungen gearbeitet?
• Ist die Dateigröße des Backends im gesunden Bereich?

 

Hallo
Frage:
ist das lokales Frontend (FE) eine AccdB oder AccdE ?
habe das hier auf anhieb niche gefunden !

 

Danke für die rege Anteilnahme,
Heute habe ich einiges probiert. UNC-Pfad bringt leider nichts.
Den Tipp mit der permanenten Verbindung habe ich umgesetzt und werde morgen das Ergebnis bekommen.
Umsetzung auf SQL habe ich schon länger im Blick, jedoch mich vor dem Aufwand gedrückt. Zahlen wollen nämlich die wenigsten dafür.

Auf dem FE läuft ACCDB.
Die Fehlermeldung ist immer "Die Datenbank ist inkonsistent und muss repariert werden" Nach der Reparatur sind alle Daten wieder vollständig ok.

Ich hoffe nun ausgiebig alle Fragen beantwortet zu haben und werde morgen Meldung machen.
Gruß Klaus