Glad to see there was some discussion around this issue. I would like to understand why there is a kill button that never actually works. Even if the process of backing out of a request takes time, couldn't that be relegated to a background process so the alert doesn't lock up the client indefinitely?
There's never any warning I'm afraid because if you aren't quick enough to catch yourself and open it in script runner you may get lucky and some portion of your work saved, but inevitably work is lost and that's no good for a developer. I've walked away in a few cases that I thought would resolve in minutes and it ran for hours. If killing the application is going to occur anyway, it seems like Toad handling it would reduce the chances of loss of work.
This process ran for a few seconds but then the process never cancels and that requires killing the application altogether.
Hi toad.user.
I'm not sure why the kill button doesn't work for you, but of course we didn't add a feature that never actually works.
When you click that button, Toad creates a separate session to the database which runs an "alter system kill session" command to kill the original session. I am not sure why this isn't working for you. Maybe this needs to be an external process, not inside of Toad.
Next time you get into that "stuck" situation, try this:
- Don't go straight to Task Manager.
- Start a separate instance of Toad
- Go into Session Browser, find the session(s) of your first instance and kill them.
Does that get you unstuck?
-John
Ok, it sounds like you're saying the button only works when more than one session is open, as I've never seen it work, but I'll give that a shot and see what happens. If that is the solution then you may want to update the alert message to advise users to open another instance if they want to kill their current session. Better still, maybe make the kill button active on a single session and have it open the second session and kill the first so the process is seamless. I've never had a need to run multiple instances so the solution is a bit counterintuitive.
Below is how long that previous example has been running on a query that only ran for a few seconds. I'd forgotten it was still running hoping it would resolve itself. When I attempt to open another instance of Toad nothing else will open. I can't click on anything in Toad because it forces focus back to the alert. That's the problem. If you try to click anywhere else in Toad the alert shimmers letting you know the screen is locked and it will not open another instance of Toad while it's locked.
I had no choice but to kill the application and anything that I had been working on may have been lost because the auto-recover doesn't always catch everything. As a developer you have to agree it's a valid concern when there is no option for the end user to mitigate code loss.
Here's another mystery since Windows 11 was installed. Why is Toad looking for printers when script runner is launched?
No, that's not what I meant. What I meant was, if you have a connection open in Toad and click "kill", Toad will create a separate database session to kill the first. It should work even when there is only one connection open in Toad.
If it doesn't work quickly (say, 5-10 seconds) then it's probably going to hang forever like that. There is no reason to wait for over a minute for "kill" to work.
Yes of course. What you are experiencing is not the intended behavior. We never want you to lose work or have to resort to end task.
Hm, do you have this option checked that allows a multiple copies of Toad to run at the same time?
I have never seen that dialog. I just searched for that text in our source code. I don't see it anywhere. Is that dialog coming from Toad or Script Runner?
Edit:
I think that's coming from Windows, not any Quest product. Although maybe we are doing something to trigger it...
https://answers.microsoft.com/en-us/windows/forum/all/waiting-for-printer-connection/765f18ba-7632-49aa-97ff-5dc392b3d9b1
It's a Win11 issue for sure, but it never happened with 10, so I'm puzzled why it would scan devices just to open an instance of another script editor. However, also a Win11 issue, if you cancel the printer message script runner doesn't open immediately. You then find yourself thinking you need to start it again and after that instance opens a second one shows up right behind it. I've seen multiple instances show up because it loads the stack and then doesn't let them kick off until whatever it's doing with the devices is resolved. It's more of an irritation than anything else.
I've been developing Toad on a Win 11 machine for a couple of releases now. I've never seen that dialog. Weird.
I suspect QSR.exe is triggering it, not Toad.
I don't have the option for multiple instances checked because I generally don't see the need for it and it prevents multiple instances from loading if your clicks misfire. Are you suggesting I check it?
The kill button is always grey, it never becomes active, and I've been using Toad for years. Despite it never becoming active it doesn't always mean I will encounter a runaway cancellation process. Sometimes it will return, but I have no way of knowing which set of circumstances will allow it to complete or not. It's a crap shoot.
I'm up for trying anything at this point, but so far nothing seems to work.
Oh, I thought you clicked it, then it went disabled, and you were waiting for it to kill the session!
But now I understand that you are saying it never becomes enabled in the first place. Ok.
For that button to be enabled, you need the following privileges:
- ALTER SYSTEM
- SELECT on V$SESSION
No, not yet. See if you can get those privs first and let's see where that gets us.
That kind of presents a problem because I access a variety of systems in different roles, as I suspect a lot of people do, and those roles aren't all going to have the same level of capabilities. In my case it's a matter of just killing a select query that inadvertently results in an application failure because for whatever reason the query can't be canceled.
Toad is feature-rich, but it's akin to walking through a field of landmines never knowing when you're going to hit one. I only use script runner when I need something running in the background because the grid system isn't as good as that default grid in the standard editor. Seems to me there should be a solution for the lowest common denominator of users.
Yes, that's the cancel button. It should work for everyone. I don't know why it's not working for you though. The "Kill Session" button is more like an ejection seat. It's not meant for everyone.
Let's start over. What can I do to reproduce this problem you experience of the "Cancel" button not working? If I can reproduce it, maybe I can fix it.
The cancel button is what sends it into the tailspin. Maybe that wasn't clear. You cancel a query and it locks up immediately and you're left waiting for it to back out of the query. Sometimes it will complete and other times it will run for hours like the example I posted earlier. Obviously no one can sit there waiting for it to let go so that results in having to kill the application and you're only going to capture from the last time autosave ran. You could have written 100 lines of code in the last ten minutes and if autosave didn't run and the system hangs, your work is toast.
Yes, it's clear that you are clicking the cancel button, and then Toad hangs.
For me, it cancels right away. What I am wondering, more specifically, is "what SQL can I run or what else can I do that will cause Toad to hang when I press cancel"
Below is a video of me running a slow SQL and cancel working as it should. I am unable to make "Cancel" not cancel immediately.
If you do something with a big cartesian join like "select * from all_objects, all_tables, all_indexes", does that cause the problem?
If you check this option, queries run in a separate thread, so there is no popup dialog while the query runs (or gets stuck trying to cancel). This will allow you to save your work or do most anything else in Toad while a query is running (or trying to cancel)
Simple queries will, more often than not, stop. However if I'm querying something with over a million records for example it will likely hang.
I will try that option and see how I do. If it's creating a separate session and let's me kill it like script runner does then it may solve the issue. Thanks.
If you need to cancel a query when that option is enabled, this is how to do it.
The ESC button works with that switch flipped to run it in a separate session. It's still doing something in the background, but it's not preventing me from doing what I need to do. I think that's the solution I was looking for, so thanks for pointing that out.
1 Like
