Subject | Re: [firebird-support] Confused about delta files [SOLVED] |
---|---|
Author | Paul Vinkenoog |
Post date | 2014-01-17T01:30:31Z |
Maury Markowitz wrote:
Including suggestions in the docs like "if you move a Firebird database, check if there's a delta present and if so, move that too" might give users the impression that moving database files around is a good idea.
What's more, if there's a delta present, then the main .fdb file is usually locked - so it can be moved or copied without risk - but the delta is live, so it shouldn't be touched unless there's absolutely no other option.
In the situation you described, the logical thing to do would have been ALTER DATABASE END BACKUP (or nbackup -N) on the original machine (once you found out the right credentials, which I believe you did).
Cheers,
Paul Vinkenoog
> > What exactly are you missing in the documentation? Notice that deltaThat's right. Although your experience seems to be exceptional, it *did* happen and it may happen to others. So a warning in the nbackup manual would be in order.
> > files are normally very short-lived.
>
> That's the issue right there. As it is clearly possible that these are not *always* short lived, this should be mentioned along with suggestions on what to do.
> More specifically, there should be a mention in the sections on moving the databases that state that if a delta file is present, it must be moved as well.In general, moving Firebird database files is a definite no-no. You copy or move Firebird databases by gbak'ing them and restoring them at the new location.
Including suggestions in the docs like "if you move a Firebird database, check if there's a delta present and if so, move that too" might give users the impression that moving database files around is a good idea.
What's more, if there's a delta present, then the main .fdb file is usually locked - so it can be moved or copied without risk - but the delta is live, so it shouldn't be touched unless there's absolutely no other option.
In the situation you described, the logical thing to do would have been ALTER DATABASE END BACKUP (or nbackup -N) on the original machine (once you found out the right credentials, which I believe you did).
Cheers,
Paul Vinkenoog