I have to take back the solution check on this. I canceled the query and I can resume editing, but I can't execute anything while that process is running in the background.
If it's not one thing, it's another.
You can keep hitting ESC, but it won't actually stop the background process and therefore not let you resume executing subsequent queries.
Not that this is a solution, but if you go to a different tab you can execute another SQL.
Are you using an Oracle client? I wonder if you'd have better luck without one.
On the login window, before you've made your first connection, uncheck "Connect using Oracle client"
Not an option in my case.
That's why I said "Before you've made your first connection".
You can't check/uncheck it if you've already connected.
I opened a new connection and it started to run it, but it wasn't returning anything. So I tried to close the tab and it prompts to confirm you want to close, then it won't close. It's just a circular issue that doesn't resolve.
I have to kill the app again.
This is the tab that you cancelled which didn't really cancel? Yeah you may have to still end-task, but at least you can save your work first.
Hopefully the no-client option will work better.
I'll try to reproduce the problem with some big tables. I've done that in the past but maybe I'll get lucky.
Ugh, please make a functional kill session button or remove it because the idea that it could happen but never is clickable constitutes developer torture.
Regretfully, this is the only kill switch, which can kill your work.
For what it's worth, the kill session button will be enabled if you have the alter system privilege and can select/read from v$session.
Have you tried starting a 2nd Toad and killing your session from there instead of end task?
I'm aware of this "cancel not working" problem but can't reproduce it reliably enough to try to fix it. 
Find yourself a table with several hundred million records and try running an expensive query on it because the dba didn't index anything and then try to kill it and I'll bet you see it.
Hi toad.user,
I've been playing with that this morning - badly joining and sorting several large tables on unindexed columns and letting the query run for various amounts of time (10 seconds up to 3 minutes) before I cancel. The explain plan is below. Both the Kill Session and Cancel buttons have been working quickly for me.
I think there is something about your environment lending itself to the problem. Do you have any other clues for me?
If you want to send me your query and table definitions (I can insert my own fake data) I will try again. john.dorlon@quest.com
-John
---------------------------------------------------------------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | Pstart| Pstop |
---------------------------------------------------------------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | | | | 2641T(100)| | | |
| 1 | SORT ORDER BY | | 8250P| 15E| 15E| 2641T(100)|999:59:59 | | |
| 2 | MERGE JOIN | | 8250P| 15E| | 90T(100)|999:59:59 | | |
| 3 | SORT JOIN | | 4132G| 770T| 1865T| 12G (10)|132:05:54 | | |
| 4 | MERGE JOIN CARTESIAN | | 4132G| 770T| | 4773M (5)| 51:47:55 | | |
|* 5 | TABLE ACCESS FULL | TARGETPROFILES | 2676K| 375M| | 8725 (2)| 00:00:01 | | |
| 6 | BUFFER SORT | | 1543K| 85M| | 4773M (5)| 51:47:55 | | |
| 7 | PARTITION RANGE ALL| | 1543K| 85M| | 1783 (5)| 00:00:01 | 1 |1048575|
| 8 | TABLE ACCESS FULL | WRI$_OPTSTAT_HISTGRM_HISTORY | 1543K| 85M| | 1783 (5)| 00:00:01 | 1 |1048575|
|* 9 | SORT JOIN | | 39M| 6016M| 13G| 1316K (1)| 00:00:52 | | |
|* 10 | TABLE ACCESS FULL | FEATURES | 39M| 6016M| | 138K (2)| 00:00:06 | | |
---------------------------------------------------------------------------------------------------------------------------------