Subject | RE: [Firebird-Java] Users Connected |
---|---|
Author | Steffen Heil |
Post date | 2005-05-31T10:56:21Z |
Hi
You really want to restore a database to a temporary file and the rename it,
replacing the "old" version?
BAD IDEA.
Even if firebird does not lock the db (which I never tried on linux - it
does so on windows) it definitely keeps it open. So if you replace the file
(or better: the filename), the file handle will still use the old file
(which is not linked in the filesystem anymore)!
Therefor every change will be lost (every change since backup and because of
the file handle even every change afterwards)!
Shut down the database completely (there is a command for this I don't
remember right now). Backup, restore, and bring the database online again...
No other way.
But on the other hand? Why would you want to backup and restore? Backup is a
good idea, so is restoring for test of validity of the backup, but restore
it somewhere else, not replacing your old db...
Regards,
Steffen
[Non-text portions of this message have been removed]
> You can restore and backup DB with worked user. Fierbird notNo. No. No. No. Never !!!
> lock DB file. I recommend restore DB in temporary file, and
> It rename to final DB name after good restore.
You really want to restore a database to a temporary file and the rename it,
replacing the "old" version?
BAD IDEA.
Even if firebird does not lock the db (which I never tried on linux - it
does so on windows) it definitely keeps it open. So if you replace the file
(or better: the filename), the file handle will still use the old file
(which is not linked in the filesystem anymore)!
Therefor every change will be lost (every change since backup and because of
the file handle even every change afterwards)!
Shut down the database completely (there is a command for this I don't
remember right now). Backup, restore, and bring the database online again...
No other way.
But on the other hand? Why would you want to backup and restore? Backup is a
good idea, so is restoring for test of validity of the backup, but restore
it somewhere else, not replacing your old db...
Regards,
Steffen
[Non-text portions of this message have been removed]