<lester@...> wrote in message news:3C7C8384.DF8A3D0A@......

>
> This sounds too simple, is it a practical way forward?

It's a high level view only. I borrowed the idea from MsSql.

> It sounds as if it could give 'performance time' information
> such as
>
> select rdb$start_time, rdb$request from rdb$requests where
> rdb$start_time > 'NOW' - (2mins)

Yes, because this information IS in the internal data structures, only that
nobody can see it without a debugger.

> I presume that the missing bit is getting the 'delete' to
> actually cancel the query?

That's the nice thing. :-)
A couple of semaphores, protecting some data structures, signaling the
request and ALL its child requests as stopped so they obey and notifying the
sorting phase (ouchhh) because with some monstrous query, sorting could be
taking 40 minutes and you'll want to interrupt it.
After all, why are we trying to interrupt a query? When it's already
prepared, it only remains to sort it if needed. Otherwise, you stop the
execution phase by simply not retrieving more rows and unpreparing the
statement. IB/FB doesn't push records to the client side.

I have a different view than the approach that BORL took and found that Toni
Martir (IBAccess) and other few people have similar ideas.

A user can cancel its queries.
Sysdba of course can kill any query.
Not restricted to that, we could bind special roles to quotas. IE some users
can't execute a request for more than 10 minutes or the request is
terminated automatically... but I'm dreaming.
Using a SQL interface to manage those issues has advantages and
disadvantages. Other people will prefer to expand the Services API to get
and modify the same information.

C.
--
Claudio Valderrama C. - http://www.cvalde.com - http://www.firebirdSql.org
Independent developer
Owner of the Interbase® WebRing