Probleme bei Wechsel auf FB 2.01

[Jörg Buhren]

Hallo alle

Im Zuge eines Neuaufbaues meines Servers hab ich den Schritt gewagt und statt FB 1.0X nun Firebird 2.01 aufgespielt. Soweit, so gut. Danach wurden ein paar Datenbanken zum Test eingegespielt Agrrr, die ODS hat sich geändert, also schön brav mit nem alten GBAK eine Backup erzeugt und auf dem neuen Server wieder mit gbak zurückgespielt.
Dabei ist mir als 1. aufgefallen, das gbak(2.01) eine vorhandene Datenbankdatei nicht ersetzen kann. Na gut, wird sie halt manuell gelöscht, ist aber schon komisch.
Dann die 1. Tests durchgeführt. Ein altes Entwicklungswerkzeug (mit IBX) kann die Datenbanken öffnen und lesen. Die alten UDF's laufen auch. Ich hab mich schon gefreut, bis ich das eine oder andere Anwendungsprogr. (mit IBO-Zugriff ) gestartet hab. Bei der Neuanlage eines Satzes (in beliegiger Tabelle) kommt mit konstanter Boshaftigkeit:

unknown ISC-Error
unknown Column RDB$INDEX_SEGMENTS.RDB$FieldName

Hab mal nachgesehen, ob das Feld umbenannt wurde, aber es existiert noch. Dennoch ist keine Neuanlage möglich.

AUs Zeitgründen hab ich erstmal auf FB 1.5 zurückgesetzt, die Testdatenbankdateien wieder mit GBak (ODS10) eingespielt.
FB1.5 kann zum einen vorhandene Datenbankdateien ersetzen, und vor allem, die IBO-Applikationen laufen wieder.
Ist das nun ein IBO- oder ein FB Problem ?
Ich hab hier etwas rumgestöbert, aber keine entsprechenden älteren Beiträge gefunden.
Falls jemand einen Tipp hat ....


Server: Debian Etch, Firebird-Versuch FB2.01 SS IBO: 4.2 Hc mit Borland C-Builder 5

[Markus Kinzler]

Versuche mal die Datenbank in ein Skript tu exportieren und dieses auf dem 2er Server auszuführen.
BTW auf Linux würde ich auf jeden Fall CS nehmen.

[Frank Reim]

Hi,

IBO unterstützt Firebird 2 erst ab der Version 4.6Bc.
Aber aus meiner Erfahrung ist erst die Version 4.7 Build 16 zu empfehlen.
Seit diesem Release habe ich keine Probleme mehr.

Cu, Frank

[Jörg Buhren]

Versuche mal die Datenbank in ein Skript tu exportieren und dieses auf dem 2er Server auszuführen.

Hmmm, ich hab nicht eine Datenbank-Datei, sondern zig. Die alle per Script zu ex- und dann zu importieren, das kann es doch nicht sein, oder.

BTW auf Linux würde ich auf jeden Fall CS nehmen.

Weiss nicht, warum ? Der Server lief ab Anf 2003 mit debian und FB1.0x SS absolut ohne Probleme. Ich hatte fast vergessen, das es überhaupt existiert

Und seit gesern abend läuft er auch wieder, aber mit FB1.54 SS. Man muss doch wohl keinen CS unter FB 2.0 verwenden?
Und meine Kunden setzen zum Grosteil Win-Server ein. Da würde ich immer den SS nehmen.

[Jörg Buhren]

Hi,

IBO unterstützt Firebird 2 erst ab der Version 4.6Bc.
Aber aus meiner Erfahrung ist erst die Version 4.7 Build 16 zu empfehlen.
Seit diesem Release habe ich keine Probleme mehr.

Cu, Frank

Ok, danke für den Hinweis. Auf der IBO-Seite hab ich so nichts dazu gefunden, jedenfalls nicht so offensichtlich.
Also steht mir ein IBO-Update in's Haus Shit, das ist unter dem C-Builder richtig dämlich und bestimmt 2-3 Tage Arbeit

[Frank Schlottmann-Goedde]

[QUOTE=Jörg Buhren;145693]Hallo alle


> Dabei ist mir als 1. aufgefallen, das gbak(2.01) eine vorhandene
> Datenbankdatei nicht ersetzen kann. Na gut, wird sie halt manuell gelöscht, ist > aber schon komisch.

gbak -rep
tut was Du willst.


> Ist das nun ein IBO- oder ein FB Problem ?


IBO ist glaube ich etwas hinterher, zumindest habe ich da so ein statement von Jason in Erinnerung.

[Markus Kinzler]

Weiss nicht, warum ? Der Server lief ab Anf 2003 mit debian und FB1.0x SS absolut ohne Probleme. Ich hatte fast vergessen, das es überhaupt existiert

Und seit gesern abend läuft er auch wieder, aber mit FB1.54 SS. Man muss doch wohl keinen CS unter FB 2.0 verwenden?
Und meine Kunden setzen zum Grosteil Win-Server ein. Da würde ich immer den SS nehmen.

Der SuperServer wurde entwickelt, weil Mircrosoft in win2000 die POSIX-Kompatibilität hat fallen lassen und deshalb die Performance in den keller ging. Da Linux aber POSIX-capable ist, würde ich hier auch die "klassische" Posix-Variante nehmen.

[Jörg Buhren]

gbak -rep
tut was Du willst.

Nööö
gbak -rep meckert, er könne die zu ersetztende FDB-Datei nicht löschen und sie wäre vielleicht in Gebrauch. Habe sie dann manuell gelöscht (sie war definitiv nicht in Gebrauch) und gbak -r ... durchgeführt.

@Markus
und welche Vorteile soll das bringen ?

Ich ändere ungern an lauffähigen Sachen. Und der SS läuft unter Linux und unter Win. Also warum soll ich zum CS wechseln.



@all
Ich habs mittlerweile auf der IBO-Seite gefunden. Steht ja auch gross rechts oben *schäm*
Ich hatte sofort in der Release-Notes geblättert.
Besten Dank schonmal für die Antworten

[Thomas Steinmaurer]

Hallo Jörg,

die Semantik hinter gbak -r wurde in FB 2.0 dahingehend geändert, dass es nun wirklich ein "Restore" und kein "Replace" ist, wie dies in FB 1.x der Fall ist. Der Grund für diese Änderung liegt darin, dass sehr viele Leute -r mit Restore assoziert haben und sich dann massiv beschwert haben, warum eine existierende Datenbank überschrieben wurde, vor allem dann, wenn ein Restore aufgrund eines Problems in der Backup-Datei nicht erfolgreich durchgeführt werden konnte. Die Datenbank war dann in der Regel verloren (außer man hat noch irgendwo sonst ein funktionstüchtiges Backup).

Zu den anderen Dingen hast Du bereits Feedback bekommen. Die ODS Änderung ist in den FB 2.0 Release Notes dokumentiert. So auch die Vorteile der neuen ODS 11. Ich würde Dir raten, unbedingt die Release Notes von FB 2.0 durchzugehen (oder auf die EKON11 zu kommen *g*) und wenn es nur die Überschriften sind. Man bekommt zumindest einen Eindruck was sich geändert hat.

IBO sollte mit FB 2.0 seit V4.7 Beta 16 einigermaßen können. Um ein IBO Update wirst Du nicht herumkommen, wenn Du FB 2.0 einsetzen möchtest. IBO 4.8 soll auch nicht mehr all zu lange brauchen. Dann soll wirklich eine vollständige FB 2.0 Kombatibilität gegeben sein.

Schöne Grüße,
Thomas

[Frank Schlottmann-Goedde]

Nööö
gbak -rep meckert, er könne die zu ersetztende FDB-Datei nicht löschen und sie wäre vielleicht in Gebrauch. Habe sie dann manuell gelöscht (sie war definitiv nicht in Gebrauch) und gbak -r ... durchgeführt.

Liegt dann vielleicht daran, dass der FB standardmässig nicht mehr mit root-Rechten läuft.

Wenn der Server Schreibrechte auf die Datenbank hat, funktioniert -rep wie angegeben.

Frank

[Jörg Buhren]

Liegt dann vielleicht daran, dass der FB standardmässig nicht mehr mit root-Rechten läuft.

Wenn der Server Schreibrechte auf die Datenbank hat, funktioniert -rep wie angegeben.

Frank

das kann sein. Der User "firebird" hatte dort vielleicht keine Rechte zum Löschen.