Firebirdforum.de

Wie man hier viewtopic.php?p=2306#p2306 unten links sieht, läuft Firebird 2.5.9 auf dem neuen Server mit DBSWIN und ALLEN Röntgendaten bis Stand Anfang Januar 2025. In der Zwischenzeit sind auf dem alten Server neue Röntgendaten hinzugekommen. Das vergaß ich auch zu erwähnen, dass wenn man das Migrations-/Portierungsangebot von DBSWIN auf VistaSoft annimmt, "nur" die Röntgendaten der letzten 10 Jahre mitportiert werden, was aber halbwegs so schlimm ist, da praktisch nur aktuelle Röntgenbilder nützlich sind. Ältere Bilder, das will nur der Gesetzgeber. In 2-3 Jahren ändert sich der Mundraum gewaltig. Ansonsten kann man DBSWIN so lassen (bspw. auf altem Server mit alter interner IP-Adresse) und auf einem neuen Server mit neuer interner IP-Adresse mit VistaSoft neuanfangen, gibt versch. Modelle und ich würde gerne mit DBSWIN weitermachen, für immer. Dank euch kann ich Firebird 2.5.9 nutzen und habe somit viele Bugfixes eingepflegt. Ob jetzt nun Firebird v3 oder v6 genutzt wird ... mir ist Sicherheit ganz wichtig. Und obwohl in 19 Jahren nie ein besonderer Vorfall sich ereignet hat (bis auf 2003 mit Blaster und 2004 Sasser) will ich auf der sicheren Seite sein.

Firebird v3 schien eine greifbare Option zu sein, da ich mittels https://firebirdforum.de/viewtopic.php?p=1078#p1078 zumindest due duerrdbswin.fdb und dem Tipp auf ODS v12 konvertieren konnte.

Kann Firebird v3 mit ODB v11.2 arbeiten? Da steht

It is worth noting that Firebird 3.x does not support ODS 11 format,

aber ist damit auch 11.2 gemeint? Werden nur .FDB-Dateien konvertiert, dann bleiben, bis auf ein paar Beispiel FDB-Dateien nur noch: security2.fdb (in firebird v3 gibt es eine security3.fdb und in FBv4 eine security4.fdb), unter /dbsdata (nicht in /FBS) ARCHIVE.FDB, XRCHECKS.FDB und die bekannte etwa 100 MB große DUERRDBSWIN.FDB.

Das heißt, du musst ein Backup der alten DB machen und anschließend unter Firebird 3.0 wiederherstellen. Dann wird das ODS automatisch konvertiert.

Gruß
Martin

Das kann man halt nicht mit der Security machen, da diese auch jeweils andere Strukturen haben. Die User müssen halt per Hand oder Script eingepflegt werden.
Deshalb haben wir unsere eigene Userverwaltung-/berechtigung und die DB bleibt immer auf SYSDBA.

Für Userumzug von security2 -> security 4 gibt es diese Anleitung: https://ib-aid.com/download/docs/fb4mig ... ger_plugin

Das Problem mit manuellen Tätigkeiten ist die Fehleranfälligkeit.
Da wir keine Administratoren auf den Kundensystemen sind, ist eine solche Anleitung nicht hilfreich.
DIe Datenbank lässt sich ja mit GBAK einfach von x auf y überführen. Das habe ich bereits mit 1.5 => 2.0 => 2.5 => 3.0 und zum Test auf 4.0 gemacht.
Warum gibts nicht einfach eine ähnliche Funktion für die Security.fdb?
Das wäre doch das einfachste, die DB auszulesen und mit entsprechenden Erstellbefehlen für die neue DB die Security zu portieren.
Für Testumgebungen besteht ja nun auch die Möglichkeit mehrere Services zu installieren und verschiedene Ports zu konfigurieren um für die Übernahmen eine Parallelinstallation zu machen.
Da ich das FB-Usermanagement gar nicht nutze und somit auch keine Datenbasis habe, hätte ich schon lange ein CopySecFB entwickelt .

bfuerchau hat geschrieben: Fr 14. Feb 2025, 10:04 Das Problem mit manuellen Tätigkeiten ist die Fehleranfälligkeit.

Klar, aber auch automatisierte sind nicht frei davon.

Da wir keine Administratoren auf den Kundensystemen sind, ist eine solche Anleitung nicht hilfreich.

Das ist nicht grundsätzlich so. Auf den Servern, wo wir hindeployen, sind wir DBAs. Das dürfte bei Firebird-Systemen häufiger der Fall sein, weil sehr wenige Windows- oder linux-Admins sich mit Firebird auskennen. Im Gegensatz zu anderen DBs sind die Anforderungen an die Systemadmins auch sehr gering, oft reicht es, dass ein bestimmter Port freigeschaltet wird und AV-Software oder anderer Blödsinn die DB-Dateien in Ruhe lässt.

DIe Datenbank lässt sich ja mit GBAK einfach von x auf y überführen. Das habe ich bereits mit 1.5 => 2.0 => 2.5 => 3.0 und zum Test auf 4.0 gemacht.
Warum gibts nicht einfach eine ähnliche Funktion für die Security.fdb?

Klar, die Usermigration von 2.5 zu 3 oder 4 ist schwergängig. Aber da sich die interne Passwortkodierung geändert hat, wie sonst? Passwörter liegen nie im Klartext vor. Man kann alle User ihre Passwörter neu angeben lassen, aber gegen was checkt man die? Und bei Anwendungen, die einen dedizierten Useraccount nutzen und die Userdifferenzierung anders umsetzen, hat man Trauer.