There are a number of ways to initiate an execution in TX DWA. Each kind of execution is handled in one of three ways. Understanding the way the executions are run can be helpful when trying to troubleshoot execution problems.
The most basic kind of execution is to simply start an execution by hand. This can include right-clicking a table or node and selecting execute, dropping a table into the execution queue, or manually starting an execution package.
TX DWA runs these execution packages through the client you currently have open. If the client crashes or is forced closed, this will cause the manual execution to fail.
Scheduled and command line executions
Getting an execution package to run at a given time using the scheduler service is the second-most common way to run an execution package. Running an execution package through the command line is less common, but TX DWA handles both of these techniques in the same way.
Since the TX DWA client is generally not running when these executions begin, a the Scheduler service or command line call starts a new instance of the timextender.exe application in the background. This instance can be viewed with the task manager or resource monitor.
This instance runs independently, so stopping the Scheduler service will not stop any running executions, and will only prevent new ones from starting. Stopping or killing the timextender.exe application will case the execution package to fail.
Multiple environment transfer and remote control execution
Starting an execution package through the multiple environment transfer tool is the third most common way to start an execution. The remote control can also be used to start execution packages, and uses the same mechanism.
Both of these packages rely on the TX DWA Server service, which is the agent that runs the execution package. No new or existing instance of the timextender.exe application is necessary for these executions to run. Stopping the Server service will cause the execution package to fail.
Notes on recovery
If something does cause an execution package that uses managed execution to fail, and the execution package contains incremental tables, it's important to resume the execution package instead of restarting it. This is because restarting the package may cause some records to be left out of the incremental table until the next time it is fully loaded.