Sean,

The GBAK issue with non-null violations is one of the issues
I'll be addressing. More generally, what I'm trying to do is
- export gbak files to XML to simplify further processing
- allow for selective restores
- allow for "pure data" restores, without schema modifications
- allow for restores of otherwise non-restorable backups

Note that
- I'm not addressing the backup side, only restore
- I'm not using the FB code or trying to replicate
functionality in Gbak: the program is intended more
as a "bulk load from backup" than an actual restore utility.
- I'm coding in Pascal, so I don't think the FB project
could use it, although the code will probably be open sourced.

Some side-effects usable by the project might well be:
- a small documentation on the gbak format
- a DTD or schema for an XML version of gbak files

Should you wonder about these choices:
- Exporting:
- having data locked in an undocumented binary format
has always made me nervous, especially considering
what is happening to Paradox. Knowing it is eventually
possible to use the sources to rebuild the data thanks
to an OpenSource license helps, but it does not guarantee
a timeframe for data availability should the database
become unavailable for one unforeseen reason or another.
- having backups available in an easily accessible and
documented XML format guarantees a "way out" with
all enterprise data in case any of these unforeseen
problems should happen, within a narrow time window
- Uploading data: the ability to selectively upload data
from a backup into an existing database like a standard
datapump would do has all sorts of implications, some
of them positive. And, yes, I know there are also negative
implications.
- Not using C++: notwithstanding any theoretical considerations
and the efficiency other developers may have noticed for
themselves, I've always found I was more productive in
Pascal than in any other language I've used over the
course of years. Although I'm coding with Delphi/Kylix,
I may try to make the code compatible with FreePascal
to ensure portability beyond Win32 and Linux.

> Date: Thu, 3 Jun 2004 19:46:41 -0400
> From: "Leyne, Sean" <sleyne@...>
>
> Fredetic,
>
> > But before I commit too much work on this subject, I'd like to
> > know if this is an area where (non compatible) changes are expected
> for
> > Vulcan and beyond.
> >
> > Where should I ask about these expected changes ?
>
> If you are referring to the format of the GBAK files? There has been no
> mention/hint or otherwise of any change anticipated to the GBAK file
> format.
>
> There are some functional GBAK items (resolving the issue of restoring
> DB with non-null violations) which are expected to be addressed in the
> next Firebird release.
>
>
> Sean
>