GFIX -shut -force leaves lock on a database file thus preventing a subsequent restore [CORE97] #421
Comments
|
Commented by: Alice F. Bird (firebirds) Date: 2004-11-19 07:39 Nickolay, the reported issue is a by-design one. Shutdown |
|
Commented by: Alice F. Bird (firebirds) Date: 2004-11-18 21:32 To the best of my memory while I fixed a bunch of issues Dmitry, are you sure that the disappeared in Firebird 2.0? |
|
Commented by: Alice F. Bird (firebirds) Date: 2004-11-17 20:36 AFAIU, this is no longer an issue for v2.0, but I'd like |
|
Commented by: Alice F. Bird (firebirds) Date: 2004-08-05 11:35 I confirm this bug with the 1.5.1 version too |
Modified by: Alice F. Bird (firebirds)description: SFID: 976756# With GFIX -force, I cannot use GBAK to perform a I'm using FB 1.5.0.4306 (super server) on winXP sp1 Full description (mostly) as posted in The -force option for GFIX does not seem to work To reproduce the bug: - use an FB client (I used IBAccess in my test) to gfix -user "SYSDBA" -password "masterkey" -shut -force When GFIX completes, the database connection gbak -R -user "SYSDBA" -password "masterkey" <backup I get: gbak: ERROR: could not drop database <database> If I then close IBAccess, the GBAK call succeeds. gfix -force does prevent new connections and it does So I can't reliably automate a database backup/restore. I don't know if this is a bug with GFIX or with FBServer. => SFID: 976756# With GFIX -force, I cannot use GBAK to perform a I'm using FB 1.5.0.4306 (super server) on winXP sp1 Full description (mostly) as posted in The -force option for GFIX does not seem to work To reproduce the bug: - use an FB client (I used IBAccess in my test) to gfix -user "SYSDBA" -password "masterkey" -shut -force When GFIX completes, the database connection gbak -R -user "SYSDBA" -password "masterkey" <backup I get: gbak: ERROR: could not drop database <database> If I then close IBAccess, the GBAK call succeeds. gfix -force does prevent new connections and it does So I can't reliably automate a database backup/restore. I don't know if this is a bug with GFIX or with FBServer. |
Modified by: @pcisarassignee: Dmitry Yemanov [ dimitr ] => |
Modified by: @dyemanovassignee: Dmitry Yemanov [ dimitr ] |
Modified by: @dyemanovTarget: 2.5.0 [ 10221 ] Fix Version: 2.5 Alpha 1 [ 10224 ] Fix Version: 3.0.0 [ 10048 ] => |
Modified by: @pcisarWorkflow: jira [ 10121 ] => Firebird [ 14322 ] |
Modified by: @dyemanovstatus: Open [ 1 ] => Open [ 1 ] Fix Version: 2.5 Beta 1 [ 10251 ] Fix Version: 2.5 Alpha 1 [ 10224 ] => |
Modified by: @dyemanovstatus: Open [ 1 ] => Resolved [ 5 ] resolution: Fixed [ 1 ] Fix Version: 2.5 RC1 [ 10362 ] Fix Version: 3.0 Alpha 1 [ 10331 ] => |
Modified by: @dyemanovsummary: GFIX -force leaves lock on database file - can't restore => GFIX -force leaves lock on a database file thus preventing a subsequent restore |
Modified by: @dyemanovsummary: GFIX -force leaves lock on a database file thus preventing a subsequent restore => GFIX -shut -force leaves lock on a database file thus preventing a subsequent restore |
Modified by: @pcisarstatus: Resolved [ 5 ] => Closed [ 6 ] |
Modified by: @pavel-zotovQA Status: No test |
Submitted by: nealo (nealo)
Is duplicated by CORE1611
SFID: 976756#
Submitted By: nealo
With GFIX -force, I cannot use GBAK to perform a
restore. Windows reports the DB file as 'in-use' until
all instances of the firebird clients (that were
connected when the -force was performed) are closed.
I'm using FB 1.5.0.4306 (super server) on winXP sp1
Full description (mostly) as posted in
mailto:firebird-support@yahoogroups.com:
The -force option for GFIX does not seem to work
correctly. As a result, I am not able to automate the
backup/restore process. I'm just following the
procedure outlined at http://firebird.sourceforge.net and
posting it here first.
To reproduce the bug:
- use an FB client (I used IBAccess in my test) to
connect to a database using a user other than SYSDBA or
the OWNER
- from a command prompt:
gfix -user "SYSDBA" -password "masterkey" -shut -force
0 <database>
When GFIX completes, the database connection
established in IBAccess can no longer do anything
(expected), but when I try to perform a restore to the
database using GBAK
gbak -R -user "SYSDBA" -password "masterkey" <backup
file> <database>
I get:
gbak: ERROR: could not drop database <database>
(database might be in use)
gbak: Exiting before completion due to errors
If I then close IBAccess, the GBAK call succeeds.
gfix -force does prevent new connections and it does
prevent existing connections from doing anything. But
it seems that the existing connection still keeps a
grip on the database file.
So I can't reliably automate a database backup/restore.
End users have a bad habit of leaving the client
application open overnight.
I don't know if this is a bug with GFIX or with FBServer.
The text was updated successfully, but these errors were encountered: