|Subject||Re: [Firebird-Architect] Can we, can we, can we????...|
> > User, even very experienced, can't prognose such things as number ofEveryone make mistakes and can, for example, miss one of the join
> > 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.
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 the1. I don't say that engine\database wide setting is a must
> data from a table - a system wide setting will cause backups to fail.
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 gbakAgreed, and i even can't imagine such switch ;-)
> ignore the system rules.