Scheduled Task TAP Execution Problem


I have tried every trick found in the forum regarding Scheduled Tasks not executing when the user is not logged into the system. I am using TDP 3.6 on Server 2012 R2. When I set to highest privilege with Server Compatibility set to 2012, the report actually runs but does encounter a “Connection failed” error. In this case, It is failing on the Oracle database connection. According to the log, “Connection description was not found in Connection Manager”.

If I set the compatibility down to Server 2008 & log the user off, the scheduled task appears to try & execute. The task library shows the task running but it never completes. That task will stay queued & no other schedule TAP will execute until I terminate that rogue session in Task Manager.

If I set the compatibility at Server 2008, leave the user logged in, but close the Remote Desktop Session to the server, the task executes fine along with all other subsequent scheduled TAPs. However, this work-around has pitfalls whenever this system is patched or rebooted by automated processes.

I have not found anything in the forum about this issue since 2013 & 2014. It appeared it was possible a bug with Windows 7 according to one thread.

As I mentioned, I am on TDP 3.6. Has the issue been fixed in future releases? Any other suggestions?



Hello Eric,

There were done few changes / fixes in the automation module and scheduler in the latest release (4.2). However I’m not able to confirm if some of them solves your problem. I haven’t seen the error before. :frowning:

It would be good if you tested the latest release. Or can you create a support request?



Hi Libor,

I am a little apprehensive about upgrading at this time as I had a few TAP issues when I upgraded from 3.4 to 3.6 two years ago. It is a possibility but I have a few daily audit reports so I am going to set up a test system. That is a good idea to open a case.



It’s not a bug. Windows does not allow a scheduled task to execute that requires a desktop window to be created if there is not currently an active desktop session for the user executing the task. Toad requires that a desktop window be created and stored in the system tray.

Hi all,

I believe I have this working now without the session logged in or a desktop window session saved in the system tray. N.B., you are correct it is not a bug but more of a multi-user configuration issue.

First of all, to clarify the operating system I am having this issue with is a Windows Server 2012 and not Windows 7 or 10 for workstations. I did open a ticket with support as suggested on the forum, and we spent 3 plus hours on the issue. The first thing I had to do was change the compatibility for the scheduled tasks to Windows Server 2012. My TAPs were first developed & migrated from Windows Server 2003 using TDP 3.0. I never had this issue until going to Windows Server 2012. Since I was downgrading my run-time user from a full-domain admin to just a regular user, I then had to check the “Run with highest privileges” check box for the scheduled task.

However, I was still having a problem with the tasks showing that they were running and queued up in task manager. I had this same issue with the full domain user account. It tuned out that when I migrated to the new server and started importing the Database Connections from one server to another, the roaming profiles were using DB connections from the import file “My Connections.xml” from a shared folder where all .tas projects and supporting files were being stored. Actually, Toad would grab that file and copy it to each c:\users***\username***\AppData\Roaming\Quest Software\Toad Data Point 3.6\ folder rather than making a “Connections.xml” file that is needed for this version of TDP. Some of the DB connections were missing as projects were developed/migrate over time. The Connections.xml file subsequently need to be copied to each user folder including the c:\users***\default***\AppData\Roaming\Quest Software\Toad Data Point 3.6.

We also continued testing and re-scheduled the project via TDP. I was still having issues and discovered the target file for this particular project was a .xls file created with DB queries that are exported correctly but the email was failing. Checking the log file generated, we discovered we needed to create an “Automation” subfolder under each user folder. Support believed that since these projects were first developed under older version, they were not using the “Automation Publishing” subfolder that is now used with the newer version (or vice-versa) if a new project was created. This “Automation” subfolder subsequently needed to be created to each user folder including the c:\users***\default***\AppData\Roaming\Quest Software\Toad Data Point 3.6.

I have tests running daily now and will see how it goes. The lesson I learned on supporting a multi-user environment for the same projects is to keep all of the AppData in-synch.

Thanks for everyone’s input on this issue!