8

I have a problem with my Firebird database. The primary key of one of the tables is referenced by another table that was actually dropped earlier. So this reference from a non-existent table was causing errors when I try to make any changes in the table data.

So I did a backup and restore and the bad reference was gone but now when I try to connect to my database more than once at the same time I get the following error:

database [file path] shutdown

How can I solve this?

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
zac
  • 4,495
  • 15
  • 62
  • 127
  • Was the table with the foreign key dropped: if so, that shouldn't lead to problems, or was the table with the primary key dropped: is so, that shouldn't have been possible. – Mark Rotteveel Jan 31 '13 at 08:45
  • @MarkRotteveel I am not quite understand what you mean but I will try to drop and recreate the table with orphan reference, I think that would solve it. – zac Jan 31 '13 at 11:49
  • It was a question: I can't tell from your description which table was dropped (the one containing the foreign key or the one containing the primary key). But in any case: that shouldn't cause issues and if it did it could point to a bug in Firebird. – Mark Rotteveel Jan 31 '13 at 11:53
  • the one containing the foreign key was dropped and any edit to the other table lead to "BLR" error. I will try and get back to you. – zac Jan 31 '13 at 11:56

2 Answers2

12

Your database (file, not server) has been shutdown, so Firebird does not accept connections for this database until it has been brought online again using gfix.

The command is:

gfix -online <path-to-your-database>

See Database Startup and Shutdown in the Firebird Database Housekeeping Utility manual

Mark Rotteveel
  • 100,966
  • 191
  • 140
  • 197
  • In addition to that solution I had to extract SQL, remove the orphan reference and create the db again....thanks Mark – zac Jan 31 '13 at 19:37
  • Is there same way how to do it if database prevents SYSDBA login by containing role with name "SYSDBA"? Usualy I have to use owner user, but if database is shutdowned, SYSDBA is required... – Honza Jul 28 '15 at 08:50
  • @Honza The only other option I know of is the database owner (if that is other than SYSDBA), as far as I know gfix doesn't support the `RDB$ADMIN` roles. – Mark Rotteveel Jul 29 '15 at 10:43
  • 2
    **Update:** I has founded solution already: `gfix -online` require SYSDBA **OR** user who shutdowned the database - if I restore database as user `test` (for example), user `test` can also `gfix -online` :) thanks – Honza Jul 30 '15 at 11:37
1

use online

gfix  -user "SYSDBA" -password "masterkey"  -online DATA.FDB

after database is used retry

gfix  -user "SYSDBA" -password "masterkey"   -shut -force 0 DATA.FDB
valentasm
  • 2,137
  • 23
  • 24