Allplan Forum: Teilbildnamen verschwinden. ProjectADMe.db3-journal?

StefanHah

31.03.2020 - 09:07 Uhr

Guten Morgen.

In unserer Workgroupinstallation haben wir seit ein paar Monaten das Problem, dass gelegentlich die Fehlermeldung "Info-Block des Teilbildes 1234 konnte nicht beschrieben werden" erscheint und alle Teilbildnamen verschwinden. Die gezeichneten Inhalte sind noch da, nur die Namen sind weg.

Im Projektverzeichnis der betroffenen Projekte existiert eine Datei "ProjectADMe.db3-journal", die in den gesunden Projekten nicht existiert und sich nicht löschen lässt.

Als Workaround funktioniert nur, das Projektverzeichnis zu kopieren (bis auf die genannte Datei) in Kombination mit dem Service-Tool REORG.
Nach ein paar Tagen funktioniert das defekte Projekt wieder einwandfrei.

Ich vermute, dass ein Netzwerk- oder Serverfehler dahinter steckt doch die Analyse gestaltet sich schwierig, da wir noch nicht wissen, wie wir den Fehler provozieren können.

Hat jemand ähnliche Probleme gehabt oder einen heissen Tip, was es mit der Datei "ProjectADMe.db3-journal" auf sich haben könnte?

lg,
Stefan

GEA Arquitectos S.L.P.
Calle Gerardo Diego 6A | 41013 Sevilla | Spain

Hilfreichste Antwort anzeigen Hilfreichste Antwort verbergen

Nemo

31.03.2020 - 10:01 Uhr *

ProjectADMe.db3-journal ist eine temporäre Datei die zur Implementierung von atomaren Commit- und Rollback-Funktionen in einer SQLite-Datenbank.
Das Rollback-Journal wird normalerweise erstellt, wenn eine Transaktion zum ersten Mal gestartet wird, und wird normalerweise gelöscht, wenn eine Transaktion committet oder rückgängig gemacht wird.

ProjectADMe.db3 ist eine SQLite-Datenbank-Datei für die Speicherung der Teilbild und Planinformationen, insbesondere des Teilbildnamens, der Ebeneninformation u.a.

Diese Informationen sind aber auch im Header jeder Teilbild-Datei(ndw) bzw. Plan-Datei (npl) vorhanden,
und weden nur wegen der Performance in der Datenbank vorgehalten.

Wenn man die ProjectADMe.db3 löscht, wird diese beim ersten Teilbildwechsel wieder neu aufgebaut.

Wenn die Journal-Datei nicht mehr gelöscht wird, könnte das auf Probleme beim Schreiben des Datei-Headers (wie die Fehlermeldung ja aussagt) zurückzuführen sein. Wenn dabei Probleme auftreten, wird kein Commit an die Datenbank gesendet, und die Datenbank bleibt "gelockt".(ProjectADMe.db3-journal wird nicht gelöscht)

Wichtig wäre es herauszufinden, warum das Schreiben des Headers der Teilbild-Datei (s. Fehlermeldung) nicht funktioniert. Es könnten sporadisch auftretende Netzwerkprobleme sein, oder mit fehlenden Rechten zu tun haben. Passiert das, wenn mehrere Benutzer gleichzeitig das Teilbild umbennenen, die Ebenen ändern oder andere Änderungen vorgenommen haben?

1 - 10 (11)

Nemo

31.03.2020 - 10:01 Uhr * [Hilfreichste Antwort]

ProjectADMe.db3 ist eine SQLite-Datenbank-Datei für die Speicherung der Teilbild und Planinformationen, insbesondere des Teilbildnamens, der Ebeneninformation u.a.

Diese Informationen sind aber auch im Header jeder Teilbild-Datei(ndw) bzw. Plan-Datei (npl) vorhanden,
und weden nur wegen der Performance in der Datenbank vorgehalten.

Wenn man die ProjectADMe.db3 löscht, wird diese beim ersten Teilbildwechsel wieder neu aufgebaut.

StefanHah

31.03.2020 - 15:07 Uhr

Vielen Dank für die Antwort!

Ich habe gerade mal versucht mit einem Kollegen simultan dasselbe Teilbild umzubennenen, bzw. einer benennt um, während der andere Ebenen zuweist, doch das hat alles fehlerlos geklappt.

Gibt es denn irgendeine Möglichkeit, eine "gelockte" Datenbank zu resetten?
Das passiert bei unseren defekten Projekten automatisch nach ein paar Tagen, ohne dass wir da jedoch bislang einen Zusammenhang z.B. mit Server-Neustarts feststellen konnten.

GEA Arquitectos S.L.P.
Calle Gerardo Diego 6A | 41013 Sevilla | Spain

Nemo

31.03.2020 - 15:28 Uhr *

Das Lock der Datenbank geschieht ja durch die "Anwesenheit" der Datei ProjectADMe.db3-journal.
Das ist diesselbe Locking-Methode, die Allplan auch für Teilbilder benutzt, nämlich über ein sog. Lock-File.

Das Lock-File erhäkt Exclusiv-Rechte, weshalb es nur der Prozess löschen kann, der es erzeugt hat.
Dieser Prozess scheint durch einen Schreib-Fehler im Teilbild-Header den Commit oder Rollback der Datenbank zu vergessen, und damit das Löschen der Lock-Datei.

Wie schon festgestellt wurde, läßt sich das Lock-File danach nicht mehr löschen, und dadurch die Datenbank nicht mehr freigeben.

Das Lock-File kann der Domänen-Administrator aber sehr wohl löschen.
Damit kann man das Kopieren des Projektes und das Reorg vermeiden.

Das sagt aber noch nichts zum Entstehen des "Dead-Locks" aus.
Ich tippe auf Netzwerkprobleme, fehlende Rechte des Prozesses oder auch eine falsche Einstellung am Server bzgl. Dateizugriff.

StefanHah

31.03.2020 - 15:55 Uhr

Vielen Dank erstmal.

Ich werde mal versuchen, das zusammen mit unserem IT-Consultor zu analysieren.
Vielleicht lässt der Inhalt des Lock-Files ja irgendwelche Rückschlüsse zu, hinsichtlich der Ursache des Problems.

GEA Arquitectos S.L.P.
Calle Gerardo Diego 6A | 41013 Sevilla | Spain

audax

01.04.2020 - 14:47 Uhr

Das ist ja interessant.
Wir haben nach dem Update von 2012 auf 2020 auch das Phänomen mit den verschwindenden Teilbildnahmen.
Allerdings 2 PC an einer NAS, ohne Workgroup.
Das Verhalten tritt in unterschiedlich Zeitabständen auf beiden Arbeitsplätzen in verschiedenen Projekten auf.
Während der Meldung infoblock etc. ist der PC für einige Sekunden wie eingefroren, auch andere Anwendung gehen dann nicht.
Im Taskmanager wird Allplan aber als "wird ausgeführt" angezeigt.
Technisch habe ich da leider zu wenig Ahnung.

Nemo

01.04.2020 - 15:49 Uhr *

2 PC an einer NAS ohne Workgroup?

Was soll denn da rauskommen, ausser Datenmüll?

Sobald 2 Benutzer auf dasselbe Projekt zugreifen endet das im Chaos!

Da braucht man sich nicht wundern, wenn Datenverluste auftreten!

Diese Konfiguration ist sehr weit entfernt von einem "bestimmungsgemäßen Gebrauch" von Allplan.
Ich hoffe sehr, das ist euch bewusst!

StefanHah

01.04.2020 - 17:18 Uhr

Wir haben es mittlerweile geschafft, eine Kopie der "ProjectADMe.db3-journal" Datei zu erstellen und in einem Viewer zu öffnen.
Ich verstehe zwar nicht genau, was ich da sehe, aber hänge mal einen Screenshot an - for future reference.

In der untersten Zeile, die auch so in "Deleted Records" steht, scheinen die Tabellenspalten verschoben zu sein.
Auffällig ist auch noch, dass beim Teilbildnamen in Spalte 6 die ersten 2 Buchstaben fehlen, wobei der 2. der fehlenden Buchstaben ein Sonderzeichen ist (kleines o mit Akzent: ó)

Das mag natürlich Zufall oder unbedeutend sein - ich werde das weiter beobachten. :-)

GEA Arquitectos S.L.P.
Calle Gerardo Diego 6A | 41013 Sevilla | Spain

Anhänge (1)

Typ: image/jpeg

98-mal heruntergeladen

Größe: 126,27 KiB

Bertrand_C

01.04.2020 - 17:29 Uhr *

Hello Stefan,

Try to replace the "ó" by a "o" and see what happens.
It's possible that this kind of charaters can bring troubles, even if everything is now in Unicode...
_______________

Versuchen Sie, das "ó" durch ein "o" zu ersetzen und sehen Sie, was passiert.
Es ist möglich, dass diese Art von Charakteren Probleme verursachen kann, selbst wenn jetzt alles in Unicode ist ...

StefanHah

01.04.2020 - 17:40 Uhr

Thank you Bertrand.

The problem is already solved, but now I want to find out, what caused it in the first place, in order to avoid future problems.
We have been using special characters in file names without any issues for years, but in the last 3 months we suddenly started to have problems with disappearing file names every now and then. It only happens roughly once per month, which makes it hard to get a grip on the problem. At least now I know how to open the corrupt database, so when it happens the next time and there are special characters involved, we have a winner. :-)

GEA Arquitectos S.L.P.
Calle Gerardo Diego 6A | 41013 Sevilla | Spain

1 - 10 (11)

Support Forum

[Frage] Teilbildnamen verschwinden. ProjectADMe.db3-journal?

Hilfreichste Antwort anzeigen Hilfreichste Antwort verbergen

Anhänge (1)