I ask because the software my company is about to start using requires a single (windows) workstation to run a small automation program each night to increment several fields in the database. I'm sure I'm not the only one who thinks this is terrible design, but there's not much I can do about it for the moment (at least until I have time to figure out what exactly it's doing and replace it with a cron-able perl script).
In the past, my only dealings with the Windows task scheduler wizard were for miscellaneous home tasks several years ago. I recall some tasks not getting executed at all, or some others only running intermittently.
Assuming the task is configured correctly, can I trust the Windows XP task scheduler to ALWAYS run this job or is it unreliable?
We have several "critical" systems where our vendors have chosen to depend on Windows Task Manager. The only problems I have ever seen would be; run times missed when the machine is off (it's not a job queue), tasks that fail simply because they were setup improperly, the executable or script itself failing every time task manager calls it and, the biggest problem of all has been, the user account set for the particular task getting locked out for any number of reasons.
To prevent the account lockout problem, I would recommend either creating a special account for the task or a little trick I have found, if the task does not need network access, you can schedule it to run as System with a blank password.
Finally, we monitor either automatically or manually all critical tasks. Just in case.
You mentioned this task was for a database. Is that database a Microsoft SQL Server? If so, you will want to look into using SQL Server Agent.
I'd say the scheduler itself is reliable as the OS it is running on.
Mostly, I've dealt with the task scheduler on Server 2000 and 2003 rather than XP but I can't recall a scheduled task failure for a task that that was related to an actual scheduler malfunction.
If that's the recommended configuration for this software, I'm sure the vendor must have confidence in the XP task Scheduler.
It's hard to say anything "ALWAYS" about a computer, but I've had generally good luck w/ the XP Task Scheduler (and the Windows Server equivalents). XP, being one of the NT-dervied OS's, has generally been pretty stable for me.
I'd give it a go.
It depends on the stability of the task. I've had it running daily jobs which end cleanly, one way or the other, running for years without issue. But I've also seen cases where a job doesn't end because the script hangs. While there is a "kill after X amount of time" configurable for each task, I've seen that fail.
I've also seen fail situations where a task is scheduled to run at periodic intervals when the job ran over the time for the next execution. Along those same lines, I had a script run every 5 minutes which queried our DNS servers. The queries finished up in about 20-30 seconds and we never saw those scripts fail when run through Task Scheduler.
I would be inclined to answer "yes" but only as long as you can be sure the machine will be running at that designated time. If the machine goes down for any reason the scheduled task will not be run when the machine reboots. i.e. The scheduler does not look to see if any schedules were missed.
If it is critical that the task runs make sure that the PC is at least plugged into a UPS.
I've had good luck with the scheduler itself running properly, though I've seen tasks fail without any clear indication due to things like permissions issues.
I'd suggest building some debug or notification code into the script that actually runs the task. That way you can passively monitor the script when it's new and occasionally monitor it as your confidence in its reliability grows.
I've never had issues with the task scheduler, however if the workstation is turned off, the application won't run (obviously).
If you're doing database level tasks, most RDBMS's will allow you to schedule a query/task to run at the DBMS level to remove reliance on third party tasks. This might be a safer method, if it's practical (same thing applies for running a cron job).
I was looking around the net a few months ago about this kind of issue, and my scrounging around came up with a clear "No" to your question.