There are a number of ways to initiate an execution in TimeXtender. 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.

Manual Execution

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.  

TimeXtender runs these execution packages through the application you currently have open. If the application 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 TimeXtender handles both of these techniques in the same way.

Since the TimeXtender application 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 cause 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 TimeXtender 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.