My scheduled reports won't run but it works fine when I run them manually. What's the problem?
It is important to understand there is ZERO difference between how a batch is run manually or scheduled using Report Runner Batch. ZERO. It runs all the same code. If it runs manually, but it will not run when scheduled, it is NOT a bug in our software (and it's NOT a licensing issue)
. There's something missing or not accessible when scheduled (see possibilities below).
Usual Answer (Usually One Of These Two Reasons):
You created User DSNs instead of System DSNs, and the user ID used to schedule the report doesn't have access to the DSN, or your report is looking for something on a mapped drive (mapped drives do not exist --- they aren't "mapped" for the Windows Task Scheduler to see).
99% of the time, the problem is related to one of the following issues (these are in order of most likely to least likely):
1) It's due to running/setting/defining the schedule without setting the ID and password, and choosing to use the System account instead. System accounts work great as long as you have the report file local to the machine. If you try to run an RPT file on the network (or batch XML file --- anything)... network resources are not available to the System account.
2) It's due to storing your reports and/or your XML files on mapped network drives. If you are not logged into your computer when the schedule runs, the mapped drives do not exist (mapped drives are actually mapped and remapped each time you log in). You'll get report not found or batch XML file not found messages in the log file.
If you look at your log file, it probably shows you're looking for a network drive that doesn't exist when scheduled. For example, let's say your report was stored on an M drive. Wherever your M drive is, it's not available when the batch runs. If you look towards the top of the log file, we show the drives that Windows tell us are available. In this sample case, it shows:
01/17/2013 10:02:00 - Drive list ----------------- C, D, E, F
As you can see, there is no M drive, even though it might exist when you run the batch manually. When run manually, your drive list might look like this in the log file:
01/17/2013 08:00:00 - Drive list ----------------- C, D, E, F, G, H, I, J, M, Z
You could technically choose any of those drives (C, D, E, F) to run the reports from, but we really recommend using our local drive set up. There is a complete Jeff-Net data folder
setup in your Public Documents here (if default installation settings used):
We recommend storing all of your Batch reports here:
C:\Users\Public\Documents\Jeff-Net\Report Runner Batch\AppData\My Reports
And your batches should be stored here:
C:\Users\Public\Documents\Jeff-Net\Report Runner Batch\AppData\My Batches
One extra benefit of this setup is you can then backup this Jeff-Net folder, and should you have any issues with this machine, you simply install the software to a new machine and copy this entire Jeff-Net folder over to "restore" your environment.
Please move your reports you want to schedule to that My Reports folder (or sub-folder).
3) You are storing batch XML files or job RPT files in a user-based documents folder and the schedule is running with a different users Windows ID/password). For example, your job is using a RPT file from C:\Users\bob.username\Documents\Reports and the Windows ID used for schedule is not bob.username... it's joe.username. In this case, joe.username does not have access to bob.username when using the Windows Scheduler. See note in #2 above about using My Reports folder.
4) You can also have an issue with mapped drives if you're running a report that looks for a file-based database on a mapped drive (like an Access database). You also can see this with DSNs that have been created to read the Access database from a mapped drive.
Note, if your report uses an Access MDB database, also make sure it doesn't have datasources linked to a mapped drive.
5) You can have another issue with mapped drives if the DSN is dependent on a DLL you have stored and registered that exists on a mapped drive. Anything to do with a DSN resource should always be stored locally and registered from your C: drive, not a network drive.
6) Make sure the Windows Tasks folder has read/write permissions (full permissions) for the user scheduling the report. This folder is located at C:\Windows\System32\Tasks (or the likes on later operating systems).
7) This is not common, but sometimes a scheduled report will not work if Integrated Security is check in the data connection properties for the RPT template in Crystal Reports. If you uncheck the Integrated Security, you may find that it works.
With the previous seven issues, there will be a log file generated to show what the problem is. Send us the log file if you can't determine what the issue is.
8) Machine was rebooted or .Net crashed.
If the log file ends abruptly, and the task is no longer running, then the machine got rebooted, or task was killed, or there was a .Net crash. If there was a .Net crash, there will be a crash notification in the Control Panel, Administrator, Event Viewer (Windows Event Viewer --- nothing related to Report Runner) at that time. If you find a .Net crash, please send us the Windows log from Event Viewer.
9) The scheduled task never started at all. There will be no log file generated when this happens, although there will be an error message in the Windows Task Scheduler. This is due to permissions or a Windows account where the ID is no longer valid or the password changed. If that's the case, you need to re-save the schedule with new credentials.
You can fix most of these issues easily by storing your reports (RPT files) and your batches (XML files) on your local drive. Do not store anything to do with scheduled reports on the network.
That's why we create the Jeff-Net\Report Runner Batch\AppData\My Batches (and My Reports) folders.
How do I find the log file?
What if there is no log file found for scheduled run time?
If you can not find a log file for your scheduled batch (and you have log files turned on of course), then the task is not starting at all
. Because, if the task starts... at all... there will be a log file. If the task is not starting at all, then you have some kind of permissions issues. This can be cause a permissions issues (noted above), the ID/password is no longer valid (noted above), or trying to schedule a Batch XML file that is stored on a mapped drive on the network (noted above). If you get the schedule ID from the Batch Scheduler, you can look up that ID in Windows Task Scheduler (button to open in Batch Scheduler). If you at your schedules in the Windows Task Scheduler, it shows messages to the right of the task. Also, in later operating systems, there is a history available for Windows tasks and you can see what the last run message is. If the task doesn't start, it's usually permissions related (see below).
What are the permissions needed to schedule a task or for the task to run?
Note: While not recommended, you can manually uncheck the option in a Windows schedule to only run when you are logged in (this is done in the Windows Scheduler). This negates part of the purpose of running tasks/schedules when you are not logged it, but it is a solution for some (or at least a temporary fix). If you do this, you must do this manually for each task. If nothing else, this will show you or your network administrator that the batch will run unattended and that it is an additional security issue keeping it from running when not logged in.
We also offer a number scheduling reports that can help shed light on problem tasks. It will also show you last run times and messages.