Re: Killing/Stopping a Sql*Net request (for end users)

From: <stu_at_sierra.net>
Date: 14 Dec 1994 02:45:07 GMT
Message-ID: <3clm7j$mgf_at_diamond.sierra.net>


In <bgmccracken.8.0032C1D6_at_amoco.com>, bgmccracken_at_amoco.com (Bill G. McCracken) writes:
>Typical situation on Windows/Mac stations is that users get impatient on a
>long running query, and need to "cancel" out of the request.
>
>Oracle Support step in any time!!!
>
>But is there a way to send a "cancel notice" to the Oracle system that
>will stop the request, once it's been submitted, and "clear" the sql*net
>channel so that theuser can get on with other transactional business?
>I know DBA or Unix Admin can "kill" the session/report, but that takes
>manual intervention by them, not the true end user where independence
>is the key.

I'm an Oracle developer, and I've done a couple of SQL*Net ports. Please note that this is my personal, not company id, so it's not official info.

The kernel can be interrupted if the application and operating system support it. For instance, SQL*Plus can interrupt a long-running select if there is a way to trasnmit the interrupt across SQL*Net. Supporting that interrupt is machine, operating system, and transport dependent. Sometimes there is no independent channel on which to send info, or the application is hung waiting to receive data from the kernel and there is no way to cancel the read so you can "write" an interrupt.

The only ones I can speak for with some authority is VM/CMS. I put interrupts in most of the SQL*Net stuff for that machine, but I don't know if my efforts survived later modifications.

I think that the need to do this is often not understood by the less experienced programmers. They are less likely to understand huge databases and the use of complex queries if they have not been out in the "customer" world. If you want to see interrupts supported better, make noise at user group meetings. It can be fixed (in theory.) Received on Wed Dec 14 1994 - 03:45:07 CET

Original text of this message