We are running scheduled batch files for various reports at 30 min., daily, weekly and monthly intervals using this method. It may seem a bit of a kludge, but it does not require ACCESS to be running all the time, nor do you have to worry about what might start running when you manually start ACCESS. When the scheduler calls the application, it will automatically start, run and exit. If you are working with an instance of ACCESS open when the schedule kicks-off, it will just open another instance of ACCESS, then close it when it has finished. It will not interfere with what you have open other than grab some processor time and perhaps the focus.
Step 1. Create a macro that will run your report using the actions "OutputTo" and "Quit". When you select the OutputTo action format, file-and-path, and encoding, etc., be sure to set AutoStart to "NO" When you select the Quit action, choose "EXIT" from its options.
Step 2. Create a batch file (anyname.bat) with wordpad in the same directory as your database file containing the following information. Be sure that the info on the lines beginning with "path" and "start" does not word-wrap to a second line(turn off word-wrap). Also do not include the < or > that have been used to hopefully make the different elements clear.
c: (or drive name where your application resides)
path = %PATH%;<drive name>:\windows\command;<drive name>:\<path to your database file's location>;<drive name>:\<path to your msaccess.exe file>
start /wait msaccess.exe "<drive name>:\<path to your database file's location>\<your database file name>" /x "<name of Macro that will run your report>"
Step 3. Using whichever form of scheduler you have, set it up to call the batch file as often as needed.
You may test the batch file by clicking on it in the windows directory.. The scheduler also gives you a manual test option.
Just ran across this recent post of additional command line options with a couple that reference user and password. Thread181-1027471 (hope the author will make it an FAQ). Haven't had a chance to try them out yet on an ACCESS database that requires userid and password.