First post to this forum. And it's about something which has irritated me for a long time - the latest crash has just annoyed me sufficiently to write this.
I've been using Toad for a while now - maybe 15 years. It's pretty good for freeware - but it's not freeware any more. Which means the way it can't reliably survive hibernate or losing connections is really poor.
It's behaved like this for all the versions I've had - every time I get a new one, I wonder "will they make it more stable?". And every time I've been disappointed.
Back in the 90s it was sort of expected that software would be a bit flaky - things crashed, you restarted and got on. But these days? Software needs to be reliable enough to run for weeks. It needs to not run out of resources. It needs to cope with simple things. And Toad is just terrible!
When are Quest going to bring the reliability of this product up to the standards expected for modern software?
Interesting. I've been using Toad from almost day one. I even contributed a bit way back when the original developer was still "in charge". Toad has come a long long way since.
I'm a DBA. I have Toad open for months with very few problems. Here are a couple I have come across:
Toad connecting to cloud databases, (Oracle and Amazon) indirectly via SSH port forwarding -- Toad needs "reconnect all" after the SSH session times out through inactivity. Toad just reconnects.
Network times out due to inactivity. Toad reconnects.
Resources are a Windows problem, not Toad. Older versions of Windows used to run out quickly. Icons would vanish from the desktop or similar. More recent versions I've been forced to use would blue screen (Win 7) or just hang (Win 10). They stay up much longer than before, but still can run out of resources.
So, question time. What, if any, error messages/pop-ups do you see?
Have you considered submitting the crash evidence to the developers?
What version of Toad?
What version of Oracle client?
Are there any other factors involvedbthat you can think of? Is outlook stealing from you, gor example?
Some actual evidence will help the developers help you.
And I can't believe you would use a "flakey" product for 15 years and not mention problems.
I am one of the developers of Toad. I've been working my tail off getting bugs fixed over the last two versions. The next version, 14.0, has over 100 bug fixes. And I'm still fixing them.
As Norm said ... give us some details. If I can reproduce something (or at least have an error log so I can pinpoint the problem), I'll fix it.
Start with the error that bothers you the most. We'll just go down the list and pick them off. But I need details.
Well, the system works. I write that post, and it's stable for today - though I've not used it much.
I'll come back when I get my next crash.
I know one of the underlying problems, excessive use of GDI objects (try seeing how Toad compares to other apps in regular use), isn't going to go away without a complete rewrite.
To the person who doesn't believe I would put up with such a flaky product (note spelling) - the feature set of Toad is sufficiently good that I put up with the pain. Raising tickets is more of a pain than restarting the app - to make problem reports useful requires more effort than I have time for, and so it goes further down my priority list.
I'm not in the habit of lying, and implying that I have done so is not acceptable.
My apologies if you think that I was implying that you were lying. I wasn't. I was saying that I personally can't believe you (or anyone) would continue to use a "flaky" product for 15 years without complaint.
(And thanks for correcting my spelling!)
Then just post here. The developers are very approachable.
I too have suffered performance issues with TOAD for many many years, but never reported them because they are so transient and difficult to pin down.
I also hibernate and resume my Windows 10 system every days for weeks at a time, and most often TOAD does not suffer any problems. I generally will have between 5-10 database connections open, each with 5-10 SQL tabs open*.
However, it is not uncommon for TOAD to just sit at "unresponding" when resuming Windows; it may also do this randomly if there is a network glitch in the middle of working, thus rendering TOAD useless until something gives it a kick to start responding. Sometimes locking the Windows session and reauthenticating gives it that kick, sometimes disconnecting the network and reconnecting, and other times a terminate the toad.exe process is the harder kick! Unfortunately none of this ever results in an actual error message, so there's nothing to report.
I too often notice the GDI object leak exacerbates the issues - it often climbs to around 6-7000 GDI objects and then TOAD starts to struggle.
I use Toad workspaces to remember these connections and SQL windows. My big gripe is that when I load a workspace, I'm forced to log in to each connection before I can use TOAD! If one of those connection is unavailable and the connection fails, all subsequent connections don't load and I have to start the whole painful process again. It would be much better to just load the workspace without connecting and then I can go to "Session > Test Connection (Reconnect)" for those that I want to use.
I've got 6 sessions, all of which were open. I went to one of the ones I'd not used for a while, pasted in a query, and hit F9. Ten minutes later (I thought I'd be generous...), still at "Toad for Oracle (Not Responding)" .
If I click on the app it goes to the windows slightly greyed out "not responding" look.
4083 GDI objects. Not much memory used at all (good sign), no CPU - it's not spinning.
The database I was trying to use is still up - it tnspings fine.
Ah, killing the connection (fortunately easy to do in this case since I was going via an SSH tunnel, otherwise I'd need to pull the wifi) has poked it into responding - it's finally noticed it's got a dropped connection.
So it smells like it's related to the code which tests for a dropped connection - which has historically been a problem (v12 would reliably die when pressing F5 on a connection which had failed, whereas F9 would successfully notice the connection had gone. v13 is substantially better at this, though I think it does still get it wrong sometimes.)
Maybe it needs to be slightly less hopeful and to properly give up if nothing is happening, rather than sitting at "not responding" while waiting for the packet which will never come.
Toad version 13.3.0.181
And a bit of a disclaimer
Paul is a colleague of mine, and we work on the same databases and probably in a similar manner. I'm not sure if we have the same version of Toad at the moment - I've normally been a bit slower at updating than him. I mentioned I'd started this thread, but didn't actually ask him to post - though it was his mention of killing the connection which helped today (had never tried that one...).
Working on errors after lost connections has been on my radar lately. I've fixed a few of these kinds of problems in 14.0, and have more in store for first beta after that, and there are a few more that I am still working on.
I have definitely heard reports of the "long time to notice a lost connection" problem, but for me that's an elusive one to reproduce. My lost connections always happen quickly. What causes your disconnects? @paul.woolcock mentioned network gitches, is that all it is or do you also have timeouts in place (ie profiles, or some kind of non-database timeout) that I can set up here to try to reproduce the hang? We've tried pulling network cables, etc, but as I said, for me, the Toad (really the Oracle client) always notices quickly.
Paul, I like your idea about Workspaces. Do you save your passwords in the login window? If you did, Toad would make those connections automatically as the workspace loads. I can reproduce the problem about workspaces not continuing to load if a connection doesn't happen. Toad can't load windows without a connection, but I could at least let it move on to windows of other connections in your workspace if one connection fails. I could also change it to make all of the connections up front and then load the windows, so that if you do have to enter passwords, they'll all be at one time rather than spaced out as the windows load.
By the way, one thing you can do that may help reconnects go faster (it won't affect hangs the first time Toad tries to run a query when connection is lost):
In Options -> Oracle -> Transactions. Set "on Test/Reconnect" to "always disconnect and reconnect". And set "When closing connections" to "Just disconnect" (Oracle docs say that a commit is automatically performed in this case for normal disconnects).
Also, you may be able to prevent timeouts in the first place by opening the "transactions" window (toolbar icon next to commit/rollback, with a question mark on it) and leaving it open while you work. Set it to auto-refresh, and then a query will run every so often in the background, hopefully keeping your session alive.
The lost connections thing doesn't seem to happen early on in a Toad session's life. As soon as I'd got your replies in this thread I tried to reproduce it, and got nowhere - it was happily noticing the failures. It seems to become more relevant when there's more connections open (or windows), and after a couple of days. So yes, it's going to be hard to reproduce - probably one for code inspection. Could it be hanging on the Oracle side - are calls to the oracle libraries blocking or non-blocking? Is there a timeout on blocking calls? Is the oracle side failing to respect a timeout? If the latter, does it need a parallel thread to make sure it doesn't block forever?
We've got some of each (blocking and nonblocking), mostly blocking, but when you run queries in the Editor with F9, for example, it depends on settings (Options -> Oracle -> Transactions -> Execute queries in threads).
We don't specify timeout in our code. I'll investigate to see if it is possible. These sqlnet.ora parameters may help:
SQLNET.RECV_TIMEOUT (read the 3rd paragraph for client side, the 1st talks about server side)
SQLNET.EXPIRE_TIME
It's just died properly - didn't respond to disconnection at all, just hung. As Paul says, in that state when you accept the Windows "close program", you don't get an error code or message.
This was trying to execute a query which might have taken a while - though I don't know if it started or not.
@JohnDorlon Sorry for the very delayed response! I haven't been able to tie it down to much more than "network" glitch, but there are various layers of VPN/DirectAccess and Zscaler inbetween me and the database server. There are no specific timeouts set that I'm aware of.
For workspaces, skipping a failed connection isn't ideal either as it sounds like I would then lose all the saved tabs and SQL therein for that connection? Maybe better to input all the passwords at the start, and then let TOAD go and makes those connections? I don't save the passwords, but manually enter them. Call me paranoid
So this is a new connection related issue. I ran some SQL, realised it may be running without an index, so cancelled it within 10 seconds or so. TOAD keeps spinning, so I click Kill Session, several minutes later, still not responsive, so I fire up SQLPlus, find my TOAD v$session and "alter system" kill it. I've even put laptop into flight mode to drop all network connections, but it just won't die! Going to have to terminate the Toad process in Windows...
v14.0.75.662
NB: If I do a manual "alter system kill session" directly in SQLPlus before attempting to use the option within TOAD, TOAD always immediately realises and I get control back.
No problem on the delay. I made a change for 14.1 (due out around March 31st, 2021) such that when you load a workspace, all of the connections for that workspace are made first, before any windows load, then after all connections are made, the windows will load. So that will minimize time between entering passwords. If a connection cannot be made, you'll have the choice of proceeding or not. If you continue without the skipped connection, that data for the connection that couldn't be made is still in the workspace, unless of course you save the workspace again without it. I have a pending enhancement request such that if a connection cannot be made, to open its editor anyway so that you can get to that work. I hope to get to that for 14.2.
I have heard of this "taking forever to cancel" problem but haven't been able to reproduce it, even with a VPN. I don't have ZScaler though. In fact, that's why I added the "kill session" button, hoping that would help. When you click that button, Toad makes a separate session just to run an "alter system kill session" on the first session.
One option might be to check Options -> Oracle -> Transactions -> Execute queries in threads.
If you do that, then at least a "taking forever to cancel" problem won't tie up the rest of Toad. In that case, the cancel button is here:
Here's one for you. Something very similar to this has happened two days in a row and generally happens about once a week. If doing this is wrong, I don't want to be right.
I copied some variables to the WHERE clause and was going to highlight and replace with an = (equals) sign. Saves on typing but not on time when TOAD barfs - which is quite often.
Blue wheel of death. Task Manager kill process. Reopen TOAD. Type it in all in over again.
Which version of Toad are you using? If it's less than 14.2, then updating to the latest should solve this. If not...
Can you give me an error log? Do get one (assuming Toad 14.2 or newer)
Right after you start Toad, go to Help -> About
Type in: freeze
a dialog will appear. Check the box and click OK, then OK again to get out of about box.
Make the blue wheel of death happen
after 15 seconds, an error should appear. click where it says "click here"
in the next dialog, check the "copy to clipboard" box (don't just try to copy the screen contents to clipboard. It won't be as complete). Click OK in that dialog.
Your clipboard will have a call stack. Post that here.
I enter the query:
SELECT FZBPMDEPX_VEN_PIDM, FZBPMDEPX_PR_NUMBER,
FZBPMDEPX_ACCOUNT_1, FZBPMDEPX_ACCOUNT_PCT_1,
FZBPMDEPX_ACCOUNT_2, FZBPMDEPX_ACCOUNT_PCT_2,
FZBPMDEPX_ACCOUNT_3, FZBPMDEPX_ACCOUNT_PCT_3,
FZBPMDEPX_ACCOUNT_4, FZBPMDEPX_ACCOUNT_PCT_4
FROM fzbpmdepx
I wanted to enter a WHERE clause => WHERE FZBPMDEPX_ACCOUNT_1 = FZBPMDEPX_ACCOUNT_2
Instead of typing it all in, I copy (from the SELECT clause to WHERE clause):
FZBPMDEPX_ACCOUNT_1, FZBPMDEPX_ACCOUNT_PCT_1,
FZBPMDEPX_ACCOUNT_2
And then highlight ", FZBPMDEPX_ACCOUNT_PCT_1," to replace it with (=) to save on typing.
When I highlight the above, TOAD locks up.
Please let me know if there is anywhere else I can recover a log from after it does lock and I'll get it to you. Otherwise, I'll note that I need to upgrade and will just use an external editor until I do have time to upgrade.
I really do appreciate your responsiveness! This is most likely the best Tech Support I've ever received either through a vendor directly but especially from a tech board posting.
I'll upgrade when I get a time slice to do so but again, I really appreciate your assistance!
