Any SUGGESTIONS here would be appreciated but I think this is so bizzare or deep into Windows that I'm not expecting any. I am developing a scheduled task that will run every morning unattended. The script starts Excel and specifies a workbook to open. The 'workbook_open' event runs and when finished, starts another batch file (via Shell(batFile, 1) and shuts down Excel. The 'batFile' starts Access and specifies the database to open. The database runs an AutoExec function and then shuts Access down. This sequence runs fours times for four separate databases. Here's the problem:

When the scheduled task runs under my account, everything works fine. However, when we change the scheduled task to run under the System Administrators account (we have to do this for reasons not important here), the sequence for one of the databases does not run. I have isolated the problem to the 'Start' commands for both Excel and Access. What appears to be happenng is that for the Excel 'Start', Excel starts but the 'specified' workbook is not opened, hence Excel just sits there as an open PROCESS not doing anything. When I changed the name of the 'specified' workbook, the Excel 'Start' works okay, opening up the renamed workbook. The same thing happens with the Access 'Start' command. Access starts but the 'specified' database does not open, hence Access just sits there as a idling process. I got around the Excel start by renaming the workbook. I cannot change the database name, however, because of other implications.

This happens with only one database and only when running under an account not my own. What could be causing the 'Start' command to not function correctly when running under the SA's account, i.e., the 'Start' command launches the APPLICATION but does not open the file specified in the command?

Thanks for any help.More info. I find that if I change the name of the folder that contains the database and change the 'start' command accordingly, the database opens.I CREATED a second parent folder and subfolder tree and renamed old and new parent folders hoping that reconstructing the folder tree would fix this. It did not. Could this be a script or task caching problem, where file pointers are corrupt and the 'start' command won't work until a reboot takes place?More info. If I remove the application name from the 'start' command and just invoke the file (e.g., "c:\file\wb.xlsm" instead of Start Excel "c:\file\wb.xlsm"), it still does not work. The command does not find the file to start the application.Thanks for the suggestion. I got around this problem by renaming the parent folder to which the folder (that contains both the workbook and the database) belongs. It's a bit of a pain since I now have to correct places that reference this path. But it works. I'll see if the next reboot CLEARS the problem. Otherwise, I don't expect to have this problem again.