On Nov 5, 2:03*am, "codefragm...@googlemail.com"
<codefragm...@googlemail.comwrote:
which brought me to this article, thanks for the help, didn't know
that.
http://blogs.msdn.com/khen1234/archi...20/483015.aspx
Bear in mind that the speed with which the DBMS responds to the
cancel signal is indeterminate. The DBMS architecture is a non-
preemptive
threading model, so for the most part, the executing thread itself
decides
when it's going to check for any external messages, such as the rare
cancel.
If it's making good progress and not needing to wait for I/O, a user
thread
may often complete before ever discovering it got a cancel signal.
Back
in my C client days I ran an experiment where I sent a long list of
individual
update statements, each inserting into a table. I sent these all in a
single
SQL string to the DBMS, and *immediately after sending the string* I
sent
a cancel. I was then able to determine how many of the rows got
inserted
before the cancel got heeded. I remember getting 472 inserts completed
out of a 500-line batch.
Joe Weinstein at Oracle