We have created around ~40 apps in Toad for oracle. Now when we are launching toad, none of the apps are present . Toad file directory in the windows folder looks ok and we see all the apps under
C:\Users<username>\AppData\Roaming\Quest Software\Toad for Oracle\16.3\User Files\AppBackups.
AppData directory points to the right location.
I'm not sure what happened, but you can import those back up files all at once.
Click here
It'll give you an "open file" dialog. Multi-select all of those backup files and they'll all import in one go.
-John
Hi John, Thanks for quick response. What are ways to identify on why this happened.
We have many apps scheduled to run at specific times and all schedules also failed with the error "Action not found:"
Is it possible that you had multiple Toads running at the same time?
If so, they could have stepped on each other while writing ToadActions.dat
You can avoid this by using the /VIRTUAL switch on your scheduled actions. This will cause the scheduled run to make a private copy of the user files folder.
FWIW, another user reported a similar problem a while back and reported back that /VIRTUAL helped him.
Just add /VIRTUAL on the command line call to Toad in the scheduled runs. There are some options with it (details in the help file) , but I think /VIRTUAL is all you really need.
Hi John,
We tried this option of VIRTUAL. Only challenge that we face is "How do we see the logs that schedule executed properly" It does not show up in the "Execution Log" any more.
Hi Mithun,
Since VIRTUAL creates its own copy of settings, it does not write anything back to the main Toad settings folder.
Can you tell by the fact that your output XLSX file got created or not?
-John
Only issue here is if output xlsx file is not created, how to investigate the failure.
In that case you could just re-run it from the main instance to see the error.
The /VIRTUAL command has some options to keep the files after it exits (see help under "run multiple toad instances" for details). But it's probably easier to just run from the main instance.
As i mentioned, today we exactly encountered the problem where scheduled failed and we could identify what step failed. If we had used VIRTUAL then we would not be able to identify the reason for failure. if we use KEEPFILES the for every schedule run it creates 25MB folder . with more than 100 schedules ,this will not be manageable. Any better way to handle this situation.
I don't have any better suggestion for version 16.3. Perhaps the best thing is to go back to not using /VIRTUAL. You can always re-import your actions from App Backups if needed. In addition, version 16.3 also has a backup system for the User Files folder. There is a User Files Backups folder full of zip files that have backups of key files, including ToadActions.dat. So that is another way you can recover from lost files.
For version 17.0: While working this, I noticed that the Automation Designer, while you are in that window, saves its settings almost every time you do anything. I made some changes so that it doesn't happen so often. If, in the case when you had scheduled actions running, if you had Toad already running and were doing things in Automation Designer. So, in some conditions, version 17.0 should be better than 16.3 at not damaging your ToadActions.dat when there is a lot of activity.
For version 17.1: Currently (in versions 16.3) we check to see if ToadActions.dat is in use before writing to it, but it seems that is not enough. I have some ideas on how I can make this code more robust. I have logged this in our bug/enhancement tracking system.
