Believe it or not I agree with you.

You can get away with whatever you like during an initial import
providing you have a working backup you can fall back on should
anything go south. Of course this means you have already restored the
backup to confirm there is no problems.

But there are other things for "one time load" processes.

1. Forced writes off, if the thing bombs, who cares.
2. Embedded is much faster
3. Disabling indices
4. Disabling triggers where applicable
5. Disabling constraints
6. Get a good balance between the time it takes to commit and start a
transaction against the resources it takes to manage the savepoint
logs.

For 4 and 5 you want to be very careful that you don't end up with a
database with issues that will make gbak refuse to restore.

For inserts after the database is being used, do not use any of the
above suggestions.

Adam



--- In firebird-support@yahoogroups.com, Nando Dessena <nando@d...>
wrote:

> Adam,
>
> A> It might be splitting hairs, but conceptually I have a problem

with

> A> committing every n transactions for the sake of performance.
>
> Oh so do I, but here we're talking mostly about one-time load
> processes which are run in single-user mode and, in case of errors
> might well consider acceptable to start over with a clean copy of

the

> database. Your mileage may vary. In such cases I tend to not

consider

> implications I would normally consider in other situations.
>
> Ciao
> --
> Nando Dessena
> http://www.flamerobin.org
> ======================================================
> I support Firebird, I am a Firebird Foundation member!
> Join today at http://www.firebirdsql.org/ff/foundation
> ======================================================