--- In firebird-support@yahoogroups.com, "Ann W. Harrison" <aharrison@...> wrote:

>
> paulfirebird@... wrote:
> >
> >>>> To summarize:
> >>>> Fill database
> >>>> Set index (takes about 6 hours)
> >>>> Create backup (which removes index)
> >>>> Create database from backup (which adds the index, again 6 hours)
> >>>> So the index is created twice.
> >>>> Is there a way to improve this? F.e. by putting a inactive index in
> >>>> the database that gets activated at the create database from backup?
>
>
> > Does anyone have an idea/solution for this?
>
> Maybe I've missed something while I was on vacation ... though this
> thread appears to have started at the end of January which is even
> longer than my average mental vacation, but ...
>
> If I remember, you're creating backups that you can distribute.
> And maybe you want to distribute them on different platforms, you
> you really need to use a gbak backup rather than a compressed
> database - though I would use a compressed database at the cost
> of having to make several kits, or have logic in the installation
> to determine the nature of the target and use the appropriate
> compressed database. Anyway, I'm assuming that you'll fill
> the database once, backup it up once, and restore it one time
> per installation. So your customer sees one 6 hour restore, not
> the original load and index creation.
>
> If by any chance you're loading, backing up, and restoring all
> on the customer site, stop it! The load and index creation is
> all you need to do ... or for additional security, backup the
> database once it's loaded to test the backup procedure.
>
> Cheers,
>
> Ann
>

I know, it has been a while, but this project I'm working on doesn't have the highest priority...

All processing is done here, so no backups at clientside.

What I want to deliver to the client is a read-only database with all indices active. I know I can do this in 2 different ways:
1: gfix -mo read_only: this has the advantage that it's (almost) instantly done (only change a couple of bits in the file)
2: do a backup and restore read-only: This has the advantage of a smaller file for distribution (-25% in our cases), but does take a lot of unnecessary calculation time (2 times index-creation a 6h each).
Especially because the first time the index is created is the last step in my process, and the next step (create backup) removes them.

For now I've chosen method #1, but it sure would please me if I get #2 working.