Hallo zusammen,
ich brauche mal wieder Eure wertvolle Hilfe, diemal in Sachen "gfix.exe".
Die gfix-Version ab FB 3.0 bringt zum Verzweifeln.
Unter der Version FB 2.5 habe ich mit folgendem Befehl:
gfix -shut -force 0 -user ".AdminUser." -password "AdminPassword." ".Database.FDB"
zuverlässig meine DB's aushängen und dann problemlos kopieren, umbenennen
oder auch löschen können.
Ab FB 3.0 habe ich inzwischen gelernt, das dort das Equivalent:
gfix -user ".AdminUser." -password ".AdminPassword." ".Database.FDB." -shut full -force 0
lautet.
Um an eine DB wieder ranzukommen, muss man dann aber noch Folgendes absetzen:
gfix -user ".AdminUser." -password ".AdminPassword." ".Database.FDB." -online normal
und meistens funktioniert das auch.
Hierfür gilt mein Dank dem Team von IbExpert, die zumindest eine Mini-Beschreibung
für das aktuelle "gfix" auf Deutsch mit brauchbaren Beispielen erstellt haben.
Dieses hilfreiche Ding im Google zu finden, war allerding schon eine Mamut-Aufgabe
zwischen den dominierenden Ergebnissen von Firebird.org mit ihrem englischen
Fach-Chinesisch.
Aber leider funktioniert das halt nicht immer so zuverlässig, wie unter FB 2.5.
Ich passe gerade einige Scripts auf die neue Syntax um, aber bei einem Script,
ein eher kompaktes gegenüber den anderen, da motzt PHP behaarlich beim
Umbenennen einer DB rum:
"Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird (code: 32) in BlaBlaBla.php"
Ich habe jetzt schon 2 Tage gesucht, aber ich habe keine Möglichkeit gefunden heraus-
zufinden, warum PHP 8.1 meint, dass ein anderer Prozess die DB verwendet / blockiert.
Alle Tools sagen, die DB sei frei und auf Command-line-ebene kann ich damit auch
machen, was ich will.
Hat bitte jemand eine goldene Idee ?
Herzlichen Dank.
gfix bringt mich an den Rand eines Nerven-Zusammenbruchs
Moderator: thorben.braun
Für eine problemlose Sicherung verwendet man das gbak, was ohne Abhängen der DB funktioniert oder via .Net-Provider, o.ä., die aufrufbare Backup-Funktion. Das Ziel ist eine portable/binäre und komprimierte Datei, die dann immer kopiert werden kann. Per Restore bekommt man dann eine saubere Kopie, wenn man sie dann mal braucht.
Wenn du unbedingt die DB abhängen willst, kannst du ebenso auch gezielt den FB-Server einfach runterfahren. Dann gibts garantiert keine Verbindung mehr und die DB kann kopiert werden.
Per CMD/BAT einfach mit
net stopt "FirebirdInstance"
net start "FirebirdInstance"
Seit 1.5 verwende ich gbak bzw. die API's der fbclient.dll. Seit Net-Firebird die integrierte Funktion, die wiederum die API's bedient.
Wenn du unbedingt die DB abhängen willst, kannst du ebenso auch gezielt den FB-Server einfach runterfahren. Dann gibts garantiert keine Verbindung mehr und die DB kann kopiert werden.
Per CMD/BAT einfach mit
net stopt "FirebirdInstance"
net start "FirebirdInstance"
Seit 1.5 verwende ich gbak bzw. die API's der fbclient.dll. Seit Net-Firebird die integrierte Funktion, die wiederum die API's bedient.
-
martin.koeditz
- Beiträge: 504
- Registriert: Sa 31. Mär 2018, 14:35
Wann erscheint diese Meldung? Wenn die DB noch offline ist?"Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird (code: 32) in BlaBlaBla.php"
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
@bfuerchau:
Für die Sicherung verwende ich ja gbak und habe auch keine
Probleme damit, ganz im Gegenteil, klappt wunderbar.
Workflow: Thema => Konvertieren von ca. 200 DBs von einer FB-Version zur nächsten.
Das ganze braucht immer ca. 2 Tage.
Ich habe 1 bis 4 Arbeits-Schritte je DB.
Wieviele Arbeitsschritte eine DB durchläuft ist abhängig vom Zeichensatz.
Die bewehrte Methode ist bisher:
Der Transparenz halber habe ich 3 Haupt-Ordner: Input / Temp / Output
a. Mit gbak erstelle ich von allen DBs eine .gbk im Ordner: Input
b. Mit gbak erstelle aus jeder .gbk eine .FDB im Ordner: Temp und verschiebe jede abgearbeite .gbk in den Unter-Ordner: Done.
c. Mit einem Script lese ich die Zeichensätze von jeder DB im Ordner: Temp aus.
Ist der Zeichen-Satz <> UTF8 erstelle ich eine UTF8-Kopie und pumpe die Daten
aus der Source-DB da rein. Verschiebe die Source-DB in den Unter-Ordner: Done
und die UTF8-Kopie in den Ordner: Output
Ist der Zeichen-Satz == UTF8 verschiebe ich die DB direkt in den Ordner: Output
d. Prüfen des Resultats.
Ist der Ordner: Temp leer und die Anzahl der .FDB == Anzahl der .gbk im Ordner: Input/Done,
dann ist alles optimal gelaufen.
Aktuelles Problem:
Um die DBs unter Punkt c. in die jeweiligen Ordner per rename verschieben zu können,
müssen sie halt vorher erfolgreich ausgehängt werden.
Dabei war BISHER gfix mein zuverlässiger Partner, aber derzeit ist er es leider nicht und
das ist halt schlecht.
Für die Sicherung verwende ich ja gbak und habe auch keine
Probleme damit, ganz im Gegenteil, klappt wunderbar.
Workflow: Thema => Konvertieren von ca. 200 DBs von einer FB-Version zur nächsten.
Das ganze braucht immer ca. 2 Tage.
Ich habe 1 bis 4 Arbeits-Schritte je DB.
Wieviele Arbeitsschritte eine DB durchläuft ist abhängig vom Zeichensatz.
Die bewehrte Methode ist bisher:
Der Transparenz halber habe ich 3 Haupt-Ordner: Input / Temp / Output
a. Mit gbak erstelle ich von allen DBs eine .gbk im Ordner: Input
b. Mit gbak erstelle aus jeder .gbk eine .FDB im Ordner: Temp und verschiebe jede abgearbeite .gbk in den Unter-Ordner: Done.
c. Mit einem Script lese ich die Zeichensätze von jeder DB im Ordner: Temp aus.
Ist der Zeichen-Satz <> UTF8 erstelle ich eine UTF8-Kopie und pumpe die Daten
aus der Source-DB da rein. Verschiebe die Source-DB in den Unter-Ordner: Done
und die UTF8-Kopie in den Ordner: Output
Ist der Zeichen-Satz == UTF8 verschiebe ich die DB direkt in den Ordner: Output
d. Prüfen des Resultats.
Ist der Ordner: Temp leer und die Anzahl der .FDB == Anzahl der .gbk im Ordner: Input/Done,
dann ist alles optimal gelaufen.
Aktuelles Problem:
Um die DBs unter Punkt c. in die jeweiligen Ordner per rename verschieben zu können,
müssen sie halt vorher erfolgreich ausgehängt werden.
Dabei war BISHER gfix mein zuverlässiger Partner, aber derzeit ist er es leider nicht und
das ist halt schlecht.
@Martin:
"Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird (code: 32) in BlaBlaBla.php"
Die Meldung kommt beim beim Verschieben einer DB per rename.
Das hat bisher aber immer perfekt geklappt, nun leider nicht mehr.
Grundsätzlich habe ich einen riesen Respekt vor der Leistung, den
die Coder von FireBird und PHP und Javascript für uns leisten, aber
manchmal gehen sie mir mit ihren immer schärferen Restriktionen
gehörig auf den Sack !
Ich bin 67 Jahre alt und weiss eigentlich was ich tue und wenn es mal
schief läuft, dann trage ich halt die Konsequenzen.
Aber diese teilweise ober-lehrer-hafte Bevormundung über immer engere
Restriktionen ist mehr als lästig, einfach Vergeudung von wertvoller
Lebenszeit.
Sorry, musste mal so raus.
"Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird (code: 32) in BlaBlaBla.php"
Die Meldung kommt beim beim Verschieben einer DB per rename.
Das hat bisher aber immer perfekt geklappt, nun leider nicht mehr.
Grundsätzlich habe ich einen riesen Respekt vor der Leistung, den
die Coder von FireBird und PHP und Javascript für uns leisten, aber
manchmal gehen sie mir mit ihren immer schärferen Restriktionen
gehörig auf den Sack !
Ich bin 67 Jahre alt und weiss eigentlich was ich tue und wenn es mal
schief läuft, dann trage ich halt die Konsequenzen.
Aber diese teilweise ober-lehrer-hafte Bevormundung über immer engere
Restriktionen ist mehr als lästig, einfach Vergeudung von wertvoller
Lebenszeit.
Sorry, musste mal so raus.
-
martin.koeditz
- Beiträge: 504
- Registriert: Sa 31. Mär 2018, 14:35
Achtung beim Verschieben der DBs. Hier hatte ich auch schonmal komische Phänomene. Wenn der Firebird-Dienst noch läuft und ich die DB verschiebe, ist diese noch immer unter dem alten DB-Pfad erreichbar. Offenbar behält Firebird den Zeiger auf die Datei, auch wenn diese nun woanders liegt. Deshalb schalte ich beim Verschieben den Dienst ab. Alternativ kopieren und dann den Alias in database.conf anpassen.
Martin Köditz
SynDesk SW GmbH
SynDesk SW GmbH
Hallo zusammen,
mir ist es gelungen meinem Nerven-Kostüm wieder etwas Ruhe zu verschaffen.
So wie es derzeit ausschaut, waren folgende Ursachen für meine Probleme
mit "gfix" verantwortlich.
1. Der FireBird-Server hat seinen Titel in der Windows-Task-Leiste verändert,
wodurch mein AutoIt-Script ihn nicht gefunden und bemerkt hat, dass über
den Windows-Task-Scheduler schon eine FireBird-Instanz gestartet war und
ordnungsgemäß eine 2. Instanz gestartet hat.
Die 1. FireBird-Instanz hat dann PHP veranlasst zu melden:
"Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen
Prozess verwendet wird (code: 32) in BlaBlaBla.php"
Damit aber nicht genug:
Entgegen früherer gfix-Versionen verlangt es für den FireBird-Server keine
Admin-Rechte mehr, ganz im Gegenteil, dann spuckt er weiter fröhlich
Fehler-Meldungen.
@Martin:
Laut IbExpert Doku garantiert der Parameter "-shut full", dass man die
DB ohne Ängste verschieben kann, bei "-shut single" ist das nicht der Fall.
Schönes Wochenende, wünsche ich.
mir ist es gelungen meinem Nerven-Kostüm wieder etwas Ruhe zu verschaffen.
So wie es derzeit ausschaut, waren folgende Ursachen für meine Probleme
mit "gfix" verantwortlich.
1. Der FireBird-Server hat seinen Titel in der Windows-Task-Leiste verändert,
wodurch mein AutoIt-Script ihn nicht gefunden und bemerkt hat, dass über
den Windows-Task-Scheduler schon eine FireBird-Instanz gestartet war und
ordnungsgemäß eine 2. Instanz gestartet hat.
Die 1. FireBird-Instanz hat dann PHP veranlasst zu melden:
"Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen
Prozess verwendet wird (code: 32) in BlaBlaBla.php"
Damit aber nicht genug:
Entgegen früherer gfix-Versionen verlangt es für den FireBird-Server keine
Admin-Rechte mehr, ganz im Gegenteil, dann spuckt er weiter fröhlich
Fehler-Meldungen.
@Martin:
Laut IbExpert Doku garantiert der Parameter "-shut full", dass man die
DB ohne Ängste verschieben kann, bei "-shut single" ist das nicht der Fall.
Schönes Wochenende, wünsche ich.
Fragen:
Wieso startest du eine Instanz via Task-Scheduler, also Aufgabenplanung, wenn der Installer einen Dienst einrichtet?
2 Instanzen verlangen auch 2 unterschiedliche Ports, Configs, Installationsverzeichnisse.
Wieso suchst du nach einem Fenster der Firebird.exe und wofür benötigst du das, wenn doch alle Firebirdtools ggf. mit dem Dienst kommunizieren?
Was übrigens auch klappt, ist den gbak mittels -server auszuführen. Dann wird der Backup durch den Dienst geregelt.
Wieso startest du eine Instanz via Task-Scheduler, also Aufgabenplanung, wenn der Installer einen Dienst einrichtet?
2 Instanzen verlangen auch 2 unterschiedliche Ports, Configs, Installationsverzeichnisse.
Wieso suchst du nach einem Fenster der Firebird.exe und wofür benötigst du das, wenn doch alle Firebirdtools ggf. mit dem Dienst kommunizieren?
Was übrigens auch klappt, ist den gbak mittels -server auszuführen. Dann wird der Backup durch den Dienst geregelt.
Hallo bfuerchau,
historisch bedingt bin ich zu FireBird gekommen, weil sie einer der wenigen,
vielleicht sogar die einzige, DB ist, die man "ohne" Port nutzen kann.
Das war für uns damals existenziell, weil unsere Software auf Firmen-PC's
installierbar sein musste, wo unsere Kunden keinen Zugriff auf die Fire-Walls
hatten, geschweige denn Dienste starten konnte.
Seither ist meine gesamte Entwicklungs-Umgebung darauf ausgelegt FB als
Application zu nutzen und ich kann keinen Grund erkennen, dies ändern zu
wollen / sollen.
Um Strom zu sparen, lege ich jeden Tag meinen Server zwischen 20:00 bis
21:00 Uhr schlafen und der wacht morgens um 07:00 Uhr wieder auf, wo
ich häufig noch schlafe, aber meine Kunden sind auch schon wach.
Damit diese dann schon arbeiten können, starte ich Apache und FireBird
per Aufgabenplanung beim System-Start.
Mit meinem Wget-CronJob funktioniert das aber nicht, wegen UAC unter
Windows und damit der seinen wertvollen Dienst tun kann, melde ich mich
halt jeden Morgen am Server an.
Das Start-Scrpt des Cron-Jobs prüft dann, welche Komponenten schon
gestartet sind und welche evtl. noch nicht und nachzuladen sind und
wertet dabei u.a. die Task-Leiste aus.
historisch bedingt bin ich zu FireBird gekommen, weil sie einer der wenigen,
vielleicht sogar die einzige, DB ist, die man "ohne" Port nutzen kann.
Das war für uns damals existenziell, weil unsere Software auf Firmen-PC's
installierbar sein musste, wo unsere Kunden keinen Zugriff auf die Fire-Walls
hatten, geschweige denn Dienste starten konnte.
Seither ist meine gesamte Entwicklungs-Umgebung darauf ausgelegt FB als
Application zu nutzen und ich kann keinen Grund erkennen, dies ändern zu
wollen / sollen.
Um Strom zu sparen, lege ich jeden Tag meinen Server zwischen 20:00 bis
21:00 Uhr schlafen und der wacht morgens um 07:00 Uhr wieder auf, wo
ich häufig noch schlafe, aber meine Kunden sind auch schon wach.
Damit diese dann schon arbeiten können, starte ich Apache und FireBird
per Aufgabenplanung beim System-Start.
Mit meinem Wget-CronJob funktioniert das aber nicht, wegen UAC unter
Windows und damit der seinen wertvollen Dienst tun kann, melde ich mich
halt jeden Morgen am Server an.
Das Start-Scrpt des Cron-Jobs prüft dann, welche Komponenten schon
gestartet sind und welche evtl. noch nicht und nachzuladen sind und
wertet dabei u.a. die Task-Leiste aus.
Jetzt komme ich etwas näher dahinter:
Du betreibst einen Apache-Web-Server auf den deine Kunden zugreifen und deine App greift sowieso ausschließlich lokal auf die DB zu, da du einen Web-Service (Backend) bereitstellst.
Für diesen lokalen Zugriff auch per Port bedarf es keiner Portfreigabe, da die Firewall nur ins Außenverhältnis zielt. Eine rein interne Port-Kommunikation via Localhost ist von der Firewall nicht beeinflusst.
Wenn man nur einen Webservice hat, kann die DB auch als embedded funktionieren und man benötigt noch nicht mal einen Batchstart.
Wir haben allerdings auch schon seit FB 1.5 immer Server bei Kunden betrieben und die Windows-Clients griffen Remote via Port auf die DB zu. Es war für keinen Kunden ein Problem, vor allem wenn wir einen lokalen Admin-Account bekamen und wir es selber verwalten, die Firewall für 3050 zu öffnen.
Du betreibst einen Apache-Web-Server auf den deine Kunden zugreifen und deine App greift sowieso ausschließlich lokal auf die DB zu, da du einen Web-Service (Backend) bereitstellst.
Für diesen lokalen Zugriff auch per Port bedarf es keiner Portfreigabe, da die Firewall nur ins Außenverhältnis zielt. Eine rein interne Port-Kommunikation via Localhost ist von der Firewall nicht beeinflusst.
Wenn man nur einen Webservice hat, kann die DB auch als embedded funktionieren und man benötigt noch nicht mal einen Batchstart.
Wir haben allerdings auch schon seit FB 1.5 immer Server bei Kunden betrieben und die Windows-Clients griffen Remote via Port auf die DB zu. Es war für keinen Kunden ein Problem, vor allem wenn wir einen lokalen Admin-Account bekamen und wir es selber verwalten, die Firewall für 3050 zu öffnen.