>> I have been working on an alternative backup program, so that I can
>> still do online backups but not get caught by gbak. If you are
>> interested you can download and read the help file at:
>> http://www.telesiscomputing.com.au/dbk.htm

> Wouldn't it be better just to fix gbak, and provide a new config
> switch that would restore and ignore all constraints?

I definitely agree that gbak should be fixed - my alternative program
is unable to achieve everything that gbak does.

However a real fix for gbak will take a fair amount of work, and a lot
more familiarity with the source than I have (I have only spent a few
hours browsing).

I dont believe a simple switch to ignore constraints is all that is
required - although I do believe this would be an important addition,
so at least data can be recovered even if structure cannot. It does
seem that there are some legal structures that gbak just cannot cope
with, and this needs resolving so that a full restore is possible when
there is nothing wrong with the database.

It is very difficult to reproduce such problems on demand, and even
harder to produce them in a database small and simple enough to be
practical for problem isolation. What I do know is that in the past I
have managed to create databases where...

Creating the database with DDL scripts and loading the data works.
Immediately doing a gbak backup and then restore either fails
completely or creates a corrupt GDB. In some instances I was able to
"fix" the database, or at least move/change the error conditions,
simply by changing the order in which the original script was applied.

Whether all my past problems still exist or have since been resolved
by various fixes to the engine I do not know - because I lost faith in
gbak and stopped using it. To begin with I setup systems that insisted
the database was offline before doing a conventional copy-style
backup, now I have my alternative online backup capability.

Of course none of this helps those of you actively involved in trying
to improve Firebird, and for that I apologise. However I had to
resolve my problems as quickly and effectively as I could using the
skills and resources that I already had. If I ever get a chance to
try isolate these problems I will be happy assist.


So yes I would like to see gbak fixed, or perhaps even re-written
with a different emphasis - data recovery first, all other
considerations secondary.

I believe my DBak application would still have use, even if/when gbak
becomes a reliable backup utility. Because of how it works and what it
does, it should still have use for database restructures, one-step
rebuilds and perhaps some other uses as well.


--
Geoff Worboys
Telesis Computing