Multiple Automation Apps Running Parallel


is there any way to run automation packages in parallel. if one of package is taking long to run as we have large amount of data, User cannot run any other packages.

Any way to allow user to run other packages while one package is running. Scheduling is not an option as user need to provide input.

There is no way to run actions in parallel within one instance of Toad, but you can start a separate instance of Toad (use the /VIRTUAL switch to prevent the two copies of Toads from trying to use the same files at the same time).

Hi John
Can this feature to execute packages in parallel be added in the upcoming release

No, I'm sorry.

The closest I could come would be to add a right-click menu item to run the action in a virtual instance of Toad. This would start a separate instance and run the action there.


Thanks. Yes that would be helpful to start with as it frees up user to use toad for other things.

hi John,
Please advise if we can get this fix as a patch on version 16.3

Hi Mithun,

Sorry, we don't make patches.



If I add a way for you to run actions in the background, you won't get any prompts for variables. You'd have to define the variables in your actions first, then run the whole thing in the background. Would that work for you?

Hi John,
That will not help as there are reports which needs input from user.
Any other suggestions/solution that we can have.

What are the actions that you are running?

If you are just running a script, maybe you can define your variables at the top of the script, and then have Toad run the script externally from Toad Script Runner or SQL*Plus


What we have done as part of Automation package

  1. Data Prep script (which takes input from customer as well)
  2. Export Dataset to create report.(excel or csv report)
  3. Cleanup all tables.

Using SQL*Plus will not help us. we can have call if required to show what we do and you can suggest us the best option.

I see. There is no way to run this in the background.

Your best option is probably to start a 2nd instance of Toad to run this if you know it will take a long time. You can start it with /VIRTUAL on the command line to ensure that there will be no problem with multiple Toads using settings files at the same time.

Then, in the 2nd instance of Toad, run your action. That way your first instance of Toad won't be blocked.

we have 500 users training them will be difficult. If a feature can be developed similar to script execution where we can run scripts in parallel . we can open support case with this request if required. Please advise.

Hi Mithun

Respectfully, opening a support case won't change anything. The support people will log your case and keep track of it, but the case would be forwarded to me to decide if it can be implemented.

A design decision was made early on for the Automation Designer to run things in the foreground, single threaded, one at a time. One of the reasons for doing so is that we can't have prompts being displayed from a background thread (what if a prompt is already being displayed in a foreground thread, or from a different background thread? - you wouldn't know which background job it is coming from). That's just one of the reasons. We cannot make the Automation Designer run jobs in the background like that.

Your options are:

  • I can give you a convenient way to send jobs to an external Toad process. In this case, you'll have to change your workflow slightly, in that the variables will need to be set before you run the job, not during the job via a popup.
  • You can start up a separate instance of Toad.

Neither of these options are difficult. I'm sure your users would be fully capable of working that way with minimal training. But there is a 3rd option:

  • Don't make any change, and let the jobs run in the foreground. The biggest bottleneck during the export process is network traffic and/or speed of the database to provide the query result. Toad's export code is highly optimized. You may not gain much overall speed by running these things in parallel anyway.

By the way - you mentioned that you want your automation task to:

  1. create a table
  2. export the table
  3. drop the table

Why not just export from the SQL that you are using to create the table, so that you don't have to create and drop the table? It seems like that would be faster.


Data prep step is not 1 query. It is 10 to 15 queries to create the data and finally export. We had to switch to multiple steps due to to limitation of queries used in data export (not able to create or drop tables)

Oh, ok. Thank you for the clarification.