> > User, even very experienced, can't prognose such things as number of
> > fetches (or page reads). Statement execution time however is usually
> > known to him. At least he can say for sure about upper time limit after
> > which statement execution must be stopped.
>
>
> The kind of user who knows what to expect from a statement doesn't write
> statements that use unreasonable amounts of system resources. A
> solution that relies on fools recognizing their own foolishness is not
> going to succeed.

Everyone make mistakes and can, for example, miss one of the join
criteria producing cross join instead of inner join and endless execution as
result. Only thing we can do is shutdown database for now.

> And, of course, gbak executes a single statement to retrieve all the
> data from a table - a system wide setting will cause backups to fail.

1. I don't say that engine\database wide setting is a must
2. gbak can set timeout to zero for own attachment\transaction\request

> And no, it's not a good idea to put in a special switch that lets gbak
> ignore the system rules.

Agreed, and i even can't imagine such switch ;-)

Regards,
Vlad