DB CREATE-Datum wird von DB Restore-Datum überschrieben - ist DAS wirklich korrekt?

[bfuerchau]

Das Problem ist dann, diese Kompatibilitybreaks dann wieder zu erkennen.
Wenn das Dateidatum oder CraetionDate dann nicht mehr stimmen funktioniert bei uns einiges nicht was dann mit Aufwand angepasst werden muss.
Da wir V4 noch nicht einsetzen, mag das dann da durchaus geändert werden.
Zumal wir mit V3 sicherlich noch einige viele Jahre auskommen können;-).
Ich bin jetzt 64, in 10 Jahren wird mir persönlich das dann egal sein.

[Gerd]

Hallo in die Runde.

So, ich habe das Anliegen via E-Mail formuliert und abgeschickt.


Viele Grüße
Gerd

Ich schrieb in etwa, (da ich es anschließend mit DeepL(R) übersetzte):

Hallo.

Das Firebird ISQL-Tool zeigt nach Eingabe von SHOW DATABASE; u.a. das Erstellungsdatum an. Ein Beispiel:
...
Erstellungsdatum: Mai 6, 2020 15:32:57 GMT
...
Wenn die Datenbank jedoch wiederhergestellt wird, wird das Erstellungsdatum überschrieben.

Ich finde es als Verbesserung, wenn ein weiterer Bereich (weiteres Feld) z. B. Wiederherstelldatum eingeführt werden könnte. Show Database; wird dadurch informativer.
In dieses neue Feld kann dann auch das Firebird Tool gbak entsprechend das letzte Wiederherstellungsdatum schreiben.
Das Erstellungsdatum - der Stempel - sollte erhalten bleiben.

Dies gilt jedoch hauptsächlich für das Firebird-System.

Ich danke Ihnen.

* * *

Und nun die mit DeepL übersetzte (und somit sinngemäße) Antwort:

Hallo!

...

Die Forderung ist klar. Unser Vorschlag ist, ein Ticket im Firebird-Projekt zu erstellen.
https://github.com/FirebirdSQL/firebird/issues

Wir von RED SOFT werden es bei Gelegenheit implementieren und einen Pull Request im Firebird-Projekt stellen.

...

Roman Simakow
Direktor für die Entwicklung von Systemprodukten
RED SOFT LTD.
...



Nun gut. Ich möchte wahrlich wegen einer Schilderung kein GitHub-Benutzerkonto erst erstellen müssen - eine darüber hinausgehende Benutzung dieser Plattform habe ich auch nicht vor.

Wer Sinn darin sieht und es auch mag, kann es (sog. Ticket erstellen) dort gerne unter seinem GitHub-Benutzerkonto tun. Danke.


Viele Grüße
Gerd

[martin.koeditz]

Hallo Gerd,

wenn Red Soft einen Pull-Request erstellt, musst du tatsächlich kein Benutzerkonto anlegen. Die Anpassung ist dann ja bereits eingetaktet. Bin gespannt, ob das übernommen wird.

Gruß
Martin

[Gerd]

Hallo Martin.

Na, das ist doch schön so.

Ich denke schon, dass sich da etwas bewegen könnte. Ob es den Sprung über RED SOFT rein nach Firebird schafft - bleibt natürlich nur zu hoffen übrig.

Immerhin hat sich der FirebirdSQL-Chefentwickler (seit 2004) Dmitry Yemanov dem RED SOFT-Team angeschlossen. Er soll dort wohl das Entwicklungsteam von Red Database verstärken und das Team von Architekten leiten.
Dort unternommenes "wird zweifellos sowohl den Benutzern als auch der bestehenden FirebirdSQL-Gemeinschaft zugutekommen", kommentierte Dmitry Yemanov.

Was mich und GitHub betrifft:
Ich finde den von mir eingeschlagenen Weg effektiver. Ansonsten wäre die dort untergebrachte und noch offene Problembeschreibung die 1.587-zigste.

Wie bereits weiter oben von mir gesagt, wenn man dem folgt wäre es schön. Lehnt man es ab, dreht sich die Welt weiter.

(Gehört zwar nicht wirklich zum Thema - aber im Kontext auch interessant:
Bei den Neuerungen von Firebird 5 (wiederhole: v5) soll es ja nun auch möglich sein die nbackup-Einträge in der RDB$BACKUP_HISTORY zu leeren.)


Viele Grüße
Gerd

[bfuerchau]

Da nun mal ein Backup oft genug auch nicht funktioniert, da ein Idiot (geplant/WSUS) gerne den Server im laufenden Betrieb runterfährt, und ich die DB dann per SQL neu erstellen und per Bulkload Tabelle für Tabelle kopieren muss (das geht nähmlich komischerweise immer), habe ich natürlich wieder eine neue DB erstellt.
Deshalb führen wir schon lange ein App-Erstelllungs und Backupdatum in einer Tabelle. Zugegeben: das kann immer manipuliert werden. Alles andere allerdings auch.