If you want to have 2 open instances of Toad going, you should probably have 2
copies installed and ran independently.
I’m still not sure what’s gained in running multiple instances,
maybe you could suggest improvements that would negate the need to do this?
If you are saving a large number of records or running a script inside TOAD, it can tie up TOAD for a long time (sometimes in excess of half an hour). The only way to do anything is to start a new TOAD.
It would be wonderful if there was a way to multithread saves and, ideally, scripts.
Thanks. Paul Knowles
Simultaneous multi-script execution within the editor is on the stack of items for 10.5. the sand ran out of the glass for this release.
Greg whipped up that little executable named “tsr.exe” in your application directory. That will be what is used to fire off multiple script engine executions. I think it may already be fully functional and useable. The great thing is it uses the same exact engine as Toad itself, unlike the “qsr.exe.” (Think “Toad Script Runner” and “Quest Script Runner”)
This just came through for me, just to conclude- there can only be one Toad instance running for the ‘Restore’ window to appear. That was the original problem.
Were you only running one instance of Toad in that test? Also, can you confirm that the tmp file includes the expected text?
Michael
Michael,
Were you only running one instance of Toad in that test?
Also, can you confirm that the tmp file includes the expected text?
just a thought that might help with this problem, maybe:
Under create a ToadTemp folder
exclusively for editor recovery files.
Create, for each instance of Toad, a folder within for recovery files.
Use a Toad (date & time of startup perhaps?) for the folder
name and store Toad's recovery files there.
On startup, look in the ToadTemp folder and offer the user the choice of
recovering files from any of the Toad folders they choose.
Of course, there may be an easier way to do this, but that's off the top
of my head and it's still morning here!
Cheers,
Norm. [TeamT]
Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else. We have checked this email and its attachments for viruses. But you should still check any attachment before opening it. We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes. If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk
Information in this message may be confidential and may be legally privileged. If you have received this message by mistake, please notify the sender immediately, delete it and do not copy it to anyone else.
We have checked this email and its attachments for viruses. But you should still check any attachment before opening it.
We may have to make this message and any reply to it public if asked to under the Freedom of Information Act, Data Protection Act or for litigation. Email messages and attachments sent to or from any Environment Agency address may also be accessed by someone other than the sender or recipient, for business purposes.
If we have sent you information and you wish to use it please read our terms and conditions which you can get by calling us on 08708 506 506. Find out more about the Environment Agency at www.environment-agency.gov.uk
Long running query in one instance locks it out. I know I could run things in background threads, but I’ve had problems in the past with that. Plus I prefer to try and keep control of the sessions opened on the database myself, rather than let Toad do that.
So, 2nd instance required to continue working on stuff/monitor the long running query, etc.
I don’t always have two instances running - only when the above situation requires it. But once open, I generally keep it open, due to there now being work in the editors that I want to keep.
Perhaps I’m not using it as it was originally designed, but there was nothing to warn me against using it like this!
but I've had problems in the past with that.
I’d try it again. The guys have done a lot of work to make the
threads/query execution stuff work as intended. You don’t want Toad to
open a separate connection to run a query, but you’re willing to open
another Toad to make another connection just to run a query? Not sure I see the
difference…
You’re other option is to run your long running queries via QSR or
SQL*Plus off the F5 dropdown control.
And what about if I kick off a long-running query that I want to cancel? Can I still do that if it’s running in the background?
Either my help-fu is failing today, or the help file is not terribly informative on the subject… (but I’m willing to bet that it’s the former!)
You can cancel any query running in Toad, threaded or otherwise.
You can see all of your running queries and cancel them as needed in the View >
Query Viewer window.
Jeff
Oooh, now that’s a bit of functionality that’s new to me… looks very handy too!
goes off to have a play *{
There are actually two ways to see queries running in threads or background.
There is a query viewer tab in the editor that shows the ones for that editor session. So if you never leave editor, you can just look there.
But if you have multiple editor open with multiple queries per running, or if you’ve shutdown the editor(s) - then you can see them all via View->Query Viewer.
This capability has been there for some time - so it’s been tested under fire - and works as advertised 