Backup / Wiederherstellen / Logbuch

Aktueller Fall: es wurde festgestellt, dass vor einiger Zeit versehentlich ein Datensatz gelöscht wurde. Per Wiederherstellen wurde ein alter Stand der Datendatei aus dem 4D Backup wiederhergestellt, um den Datensatz per Ex- und Import in die aktuell laufende Datendatei zu bringen.
Leider meldet 4D beim Starten der wiederhergestellten Datendatei (mit einer Kopie der Struktur), dass das Logbuch nicht in die Datendatei integriert werden kann, da es zu neu ist - logisch. Ich will es aber gar nicht integrieren - wie kann ich die Version trotzdem starten?

(Eine Möglichkeit wäre, das Logbuch umzubenennen, was im laufenden Betrieb aber wohl nicht anzuraten ist. Eine andere, einen anderen Rechner zu verwenden, was aber erstmal das Kopieren der großen Datendatei bedeuten würde und eine Lizenzierung von 4D auf dem anderen Rechner voraussetzt. Beides also nicht optimal.)

ich weiß nun nicht, was genau Sie beim Restore gemacht haben. Wenn ich aus laufendem 4D den Restore irgendeines alten .BK mache, dann habe ich in diesem Ordner Struktur und Datendatei ohne Logbuch. Wenn ich die starte, dann wird nach dem Logbuch gefragt und ich lege ein Neues an. In der nun geöffneten DB ist mein Datensatz noch drin und ich kann drauf zugreifen, um ihn z.B. zu exportieren.

Nur mal als Idee, hätten Sie noch ein altes BL mit diesem DS, dann LOG FILE TO JSON und so auf die Werte des Datensatzes zugreifen. Geht ab v15 R4 bzw. v16.

Die aktuelle Datenbank läuft. Components, Plugins etc. (nicht Preferences) und 4D dupliziert, Wiederherstellen -> .4DBK Datei ausgewählt. Nach Wiederherstellen diese Struktur gestartet: leider kommt eben nicht der Dialog mit der Frage nach dem Logbuch, sondern es wird automatisch auf das Logbuch der laufenden Anwendung zugegriffen.

LOG FILE TO JSON schaue ich mir an, danke.

Und die aktuelle DB kurz zu beenden ist keine Option?

Der Pfad des Logfiles (*.journal) ist m. W. in der 4DD eingetragen, und nicht in der Backup.xml.
Ich würde mal probieren, die Zweit-DB umzubenennen (4DC und 4DD), vielleicht “vergisst” 4D dann den Pfad. Ist aber nur so eine Idee.

also ich weiß jetzt echt nicht mehr, ob ich die aktuelle DB weiter laufen hatte und eine zweite version parallel dazu gestartet hatte. Ich glaube ja, spare mir jetzt aber den Test.

Aber wie dem auch sei, diese ganze Aktion ist eine Ausnahme-Administrations-Aktion. Ich rette dem Kunden Daten, die aufgrund von bösem Willen oder Fehlern oder … zu Datenverlust geführt haben. Ist die .4DD zu groß zum Kopieren, was aber bei einer SSD vielleicht nicht das Problem wäre, sollte jeder akzeptieren, daß es zu einer kurzen Downtime kommen kann. Danach ist dann aber alles wieder vorhanden.

Hmm, heute wieder gehabt. Diesmal die DB beendet, das vorletzte Backup wiederhergestellt. Meldung beim Start:
[]21832369;“Logbuch”[/]

Danach die Empfehlung, das letzte Vollbackup wiederherzustellen und das MSC wird gestartet. Wiederhergestellt hatte ich aber schon. Die Datenbank kann erst gestartet werden, wenn das Logbuch umbenannt wird. Eine Vorgehensweise, auf die man erstmal kommen muss.

auf die Gefahr hin, daß ich mich nicht mehr richtig an den Ablauf von vor 3 Wochen erinnere. Aber vielleicht erwarten Sie ja keine Antwort. Wenn ich das vorletzte Backup und das aktuelle Logbuch nehme, die passen nicht zusammen. Es hilft dann nur, alle seitdem geschriebenen Logbbücher nacheinander einzupflegen.

Nein, das ist nicht das Thema. Das Problem ist, dass man kein anderes Logbuch auswählen kann, wenn sich 4D aus irgendeinem Grund das falsche nimmt.

Die Datenbank startet, stellt fest, dass das Logbuch nicht passt, bringt obige Meldung und startet das MSC oder beendet wieder -> Endlosschleife, bis man das Logbuch findet (was u.U. gar nicht so einfach ist) und umbenennt. Wesentlich anwenderfreudlicher wäre, wenn man in dem Fall den “Logbuch nicht gefunden” Dialog aufrufen könnte, der erlaubt, ein anders auszuwählen oder ein neues anzulegen.

Also wohl eher ein Fall für einen Feature Request - leider bräuchte ich dazu wohl die englischen Texte der Fehlermeldung aus o.a. Screenshot.

Es ist natürlich ein Problem, das nicht jeden Tag auftritt. Wenn es allerdings passiert, liegen oft die Nerven eh schon blank :-?

Und nebenbei noch ein kleiner Bug: die Nennung der internen Methode “MESS_COMMON.automatic_font (runtime)” hat meiner Ansicht nach in einer Fehlermeldung für den Endanwender nichts zu suchen.

Genau das nervt hier auch.
Und das Thema tritt jeden Tag auf.

Wir entwickeln zur Zeit auf Kopien unserer DB des Vortags.
Immer beim ersten Öffnen wird nach dem Logbuch gefragt.
Genau so wollen wir das. Alles gut bis hierher.

Klickt man den Button “öffnen” wird immer das auf dem EntwicklungsPC zuletzt ausgewählte Logbuch vorgeschlagen.
Und das ist das von “gestern”. Denn bei uns heisst die Kopie der DB des Vortags jeden Tag gleich. Jede Kopie liegt in einem eigenen Ordner über den wir die Instanzen unterscheiden können.

Heute öffne ich aber eine andere Instanz der DB aus einem anderen Ordner und wenn ich nun nicht aufpasse und aus Versehen das Logbuch von gestern, das mir vorgeschlagen wurde öffne dann klappt das nicht.
Das ist ja in so weit richtig und das gewünschte Verhalten.

Ich habe aber keine Chance meinen Verklicker zu berichtigen. Sondern muss meine Kopie der DB löschen, neu aus dem Sicherungsmedium kopieren und nochmal öffnen.

Karmisch… vielleicht. Um Entwickler zur richtigen Konzentration zu zwingen.

Gruss Angelika Maser

Den Ablauf bei meinen vorigen Tests hatte ich schon wieder vergessen, daher habe ich es jetzt erneut gemacht. Da sieht man es leider, ich halte mich selbst nicht an unsere Empfehlungen. Man soll das Restore an der Anwendung beim Kunden schriftlich zweifelsfrei dokumentieren und üben. Dann das Dokument auch im Problemfall noch wieder finden. Dann wird es auch im Ernstfall unter Druck klappen.

Normalfall ist sicher, ein automatischer Restore und integrieren des letzten Logs. Das funktioniert voll automatisch, wenn am Server so eingestellt. Das ist der Standardweg. Funktioniert einfach und ohne nachzudenken. Alles andere ist Ausnahme und erfordert ein manuelles administratives Vorgehen. Sollte nicht die Regel sein und dann, wenn nicht geübt und nicht dokumentiert, mag es in der Nervösität des Ausnahmefalls Unsichertheiten und Durcheinander geben.

Weg 1:
Restore der Backup-Datei, z.B. BK[0002]. Noch ein Restore der zugehörigen Logbuch-Datei, z.B. BL[0002], würde daraus BK[0003] machen. Restaurierte DB öffnen und das eben restaurierte Log (heißt eigentlich Journal) wählen. Alles bestens.

Weg 2:
4D starten und MSC öffnen, damit die DB öffnen. Nun auf Restore, BK[0002] wählen, Option 1 oder mehrere Logfiles integrieren. Nach der Integration des einen, der benötigten in der Reihenfolge oder aller Logs abbrechen. Dann auch hier die zusammengehörenden Dateien mit 4D öffnen. Alles bestens.

Ja, in beiden Fällen müssen Sie wissen, was Sie öffnen. Ok, es gibt aber die Möglichkeit, beim Restore alles ganz woanders hinzulegen, als 4D oder MSC es vorschlagen. Das kann halt dann nicht automatisch an der richtigen Stelle gefunden werden. Außer, man denkt gleich beim Restaurieren daran. So sollte das ohne Probleme funktionieren.

Nun könnten Sie noch sagen, wenn ich einmal dann doch aus Versehen das falsche Logfile ausgewählt habe, dann soll bei jedem weiteren Versuch zu starten wieder der Auswahldialog kommen, um nun das richtige Logfile zu wählen oder im Zweifel um jetzt ein neues Logfile anzulegen. Gut, das mag einen Feature Request unter forums.4d.com wert sein. Für die englischen Screenshots die Anwendungssprache am Mac einfach euf Englisch stellen und 4D neu starten.

Hoffe, das hilft so weiter.

Hier der FR: http://forums.4d.com/Post/DE/22558419/1/22558420