Time Driven Geoprocessing Tool

junespina

Hi,

Hello, I recently created a model which automates convertion of XY tables from SQL Server to a point feature class. My job is to run this model on a daily basis, or everytime the SQL Server table is updated. My question is, is there a Geoprocessing Tool or which allows the model to run on its own after a pre-defined period i.e. 5 min, 10 min etc.

Does anybody have an idea? Thanks in advance.

Jun

Hi,

Does anybody know a script in phyton which automatically runs a model, after a pre-defined period i.e. 5 Mins, 10 Mins etc.

Thanks

Jun

RichardFairhurst

Hi,

Hello, I recently created a model which automates convertion of XY tables from SQL Server to a point feature class. My job is to run this model on a daily basis, or everytime the SQL Server table is updated. My question is, is there a Geoprocessing Tool or which allows the model to run on its own after a pre-defined period i.e. 5 min, 10 min etc.

Does anybody have an idea? Thanks in advance.

Jun

Since this only has to run on one machine, you can configure Windows Task Scheduler to run the script as frequently as you like.  It should be located under All Programs/Accessories/System Tools in your Windows Start menu.  You can supply your password to ensure it will run if your machine is not logged in, although you should disable any sleep or shut down policies on the machine if you want it to run fully unattended.

Just export your model to a Python Script and set Task Scheduler to run it at the interval you want.  You might want to add some arcpy logic to first verify if there are actual data changes present and customize the script to stop if nothing has changed, rather than complete the script when it is not needed.  Task scheduler logs a start time and finish time of every task and a finish status of the script to indicate if it ran correctly or shut down unexpectedly.  I use it for weekly updates, but supports most any schedule.

Just be careful to fully troubleshoot your code if it is updating live accessed data, because long model processes may create more disruptions than they are worth and many scripts that work fine in a single user environment fail under those conditions.