Hello André,

> How about copying an *.fdb while transactions are running and later
> just copying it back?

It is probably more robust than you give it credit for. My guess is
that there will be a lot of stuff that will need to be garbage
collected, but it is unlikely to be a problem in my experience. Still,
don't do it.

> How about making a restore while users are connected and active?

Your fbk file will still be in tact, Obviously, no database will
survive deleting the database file(s) which is the first step inside
the restore process.

> I am sure that there are more possibilities :)

I am not arguing that a careless developer could not make the database
unusable, I mean if I was to write a query

delete from RDB$Relations

I imagine FB would not work so well, but that is not really the issue.
A careless developer COULD write a query that has an abismal plan and
eats up the server resources to the point where no other user could
practically use the system, and FB currently lacks the tools to locate
and "kill" these queries.

The big + with FB in my experience is that providing the developers
behave themselves in a reasonable manner, the database will not have
any problems.

Reasonable Behaviour:

No transaction will be left open for unneccessary amounts of time.
This means nesting it inside try except end statements.

No query will be included in a release that has not had its plan
checked first.

Whenever a query / SP / trigger is written, I full list of every SP /
Trigger that could be called is made, so that recursive infinite loops
are prevented.

Adam