Toad World® Forums

Toad crashes too often

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.

Norm. [TeamT]

Hey Clive,

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.


Morning Clive,

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.

Norm. [TeamT]

1 Like

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.

Didn't take too long :slight_smile:

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

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...).

Hi Clive and Paul,

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.


Ta for this.

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)

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.