>Once in a blue moon the network may be unavailable or something, the drive disconnects, and doesn't automagically reconnect. It's been so since DOS days and never got really fixed.
>

Explains a lot.
I have a client that seems to get a blue moon most months.


>>Your program will be started in a Windows System Folder
>>I use this to change the current directory to my exe folder:
>>

CD (JUSTPATH(SYS(16)))

>
>In the TSch, there's a "Start in" textbox, where you can set the launch folder. Whichever moron wrote that dialog, forgot to add some basic validation - so, two things that you need to beware of:
>- no trailing backslash!
>- no quotes around it even if it contains spaces!

Aha!
That explains why I gave up on getting the "Start in" textbox to work properly.


>Or else your task will fail silently. The error messages in the event log will give you negative information (when you read them, you'll know less). Learned this the hard way.

The fail silently is probably the biggest caveat.
I have my tasks send me sms "Happy and Working" messages every day at the same time.
The same time is important - if it fails, you will get curious as to why you did not get your daily happy message.


>As for the account under which the task runs, YMMV. You may run it under your own account because it has a password which never changes. The value of never may change when their admin quits in disgust and new one doesn't know why is this 'never' in there. Or something nasty may happen on their system, and they may hire some IT cops to strengthen their security (always after the fact) and they may revoke that never, without telling anyone. Their job description is to make everyone's life less pleasant and they have a vow of silence. You never know what they may do, and they never tell. So I prefer the other approach, some account with official looking name, with password which never changes, and just enough rights to run this task.

The IT cops job is to stop software from working.
Keep this in mind.


>Why is this password thing important? Because when it expires, it will be changed, but it will NOT be changed in TSch, because your task runs silently and without a problem and everyone forgets about it. Two months later (sometimes four) someone will notice that the task isn't running and once they get your attention your exe better be able to deal with the backlog.

Dragan, backlog is another excellent point.
I have some scheduled tasks that create files and FTP or SFTP send the files to another company.
It is dangerous to assume that every file you create can be sent at this moment.
There may be an interruption in the internet connection, the IT cops at the receiving company can invalidate your FTP credentials, or there may be a meteor shower - ANYTHING may happen, and eventually does happen.

So, yes, your exe better be able to handle the backlog.

Good points all.
I detect the tribulations of real-world experience in your comments ;)