This is a very nice thing. Users are often quick to press a button, and
start a lengthly request. Maybe they forgot to put in some criteria to
narrow a search, or maybe they just pressed the wrong button. Or maybe
they start a long running report, and then get a telephone from a
customer. Instead of having to tell the customer to wait a few minutes,
-the system isn't responding right now, he can abort the report, help the
customer and restart the report. So I think that being able to cancel and
rollback a request at any time is a very nice thing indeed. An ability
for an Administrator to stop a never ending query without having to
restart the server is also very nice to have.

Trond.

>
>
> Leyne, Sean wrote:
>
>>> ...isn't the better solution a SQL analog of the isc_unwind_request
>>>
>>>
>> call?
>>
>> Yes.
>>
>>
>>
>>
> OK, let's look at that. There are two problems with
> isc_unwind_request. One is that it doesn't work on SQL statements, the
> other is that it doesn't actually work.
>
> New model:
>
> 1. isc_statement_info makes a available a request "token"
> 2. The "request token" is used in a separate connection to kill a
> running request. Dpb parameter? New statement? Don't care --
> anything would work.
> 3. A polite request to kill an active request with a given token is
> honored as long as the attachment accounts were the same.
>
> This doesn't require a change to the API or plumbing and could be
> implemented in an afternoon.
>
>
> [Non-text portions of this message have been removed]
>
>
>
> Yahoo! Groups Links
>
>
>
>
>
>

--
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/