Here is another couple of bits of advice.
1. Don't run this too often. The computer has to be on, but if the machine doing this is normally idle, you won't have a problem. If other people can be using the machine, though, they can provide competition for system resources. This includes the "virtual memory" file (also called the Page file or Swap file in some circles). If too much is going on, the VM file can be allocated to the point that you can't allocate space for this separate instance of the stand-alone DB that will do this task. In summary, if it is not a dedicated machine, be aware that resource contention will be at least potentially an issue. And since it will be "blindly automated" (or what we used to call "lights out" automated), there is no human in the loop to make a judgment call that it might be a good time to delay the process.
2. In essence, you are using the Access command-line option /X:macro-name to trigger a sequence of events. Just remember that the macro MUST end with an Application:Quit step. Otherwise you leave the DB dangling and the next run will trip over the remnants of the previous run. And every step of the process needs to be tested to assure that the whole sequence is robust. TEST the process manually several times. If you can make it run at least 10 times without it getting hung up in some way, then you have made some progress. In fact, if you are going to use the Windows Task Scheduler for this, it is a rule that you MUST make the thing you are going to run totally self-sufficient.
3. (2nd instance of saying it) Don't run this too often. You have a lot of networking "handshakes" to accomplish (OK, Access and Windows do the hand shakes; you don't) and they take time. I suggest manually triggering the DB from a command prompt a few times so that you can establish some sense of timing on the process. The general rule for such processes is that if you must run it more often than twice the approximate time for a single run, that you might trip on the remnants anyway, just based on timing alone, not on failed programming.
EDIT (for clarification): If it takes x seconds to run, don't run it more often than about ever 2x seconds.
4. Delegate yourself or some other person to every so often check on the computer doing this if it is one you have set aside for the purpose of this workbook upload. If the process is "between cycles" and appears to be quiet, a quick Compact & Repair might be a good idea during the "every so often" part of this. You should understand that even a fully automated process, when Access is involved, will eventually develop database bloat to the point of needing help.
5. Of course, don't forget that if you have VBA involved, the macro's RunCode action ONLY activates FUNCTIONS, not subroutines.
