Sorry I'm a data architect so I have a problem with trusted connection. Unless you have a bullet proof network (few organizations have) you should never allow trusted connections to your databases. The problem is not the access to the database. The local machine options housekeeping system paths cached reports path is the same as the scheduling server cahed reports path. I noticed that every time you open CRD and preview a report it creates a cached report instance in the cached reports subdirectory. The cached instances of the reports remain in the subdirectory and they are locked by the client session unless you exit from your local CRD session.

Can this be causing the problem. Report being cached by CRD and locked by the user session while the client session is out there? Therefore the access denied error is not access denied to the database but access denied to the cached report instance or the cache report instance parameters. Do the cache report subdirectory needs to be set for each client install regardless of whio's scheduling to avoid conflicts?

You might have hit the nail on the head for your circumstances. When a schedule is created, a cached copy of the report is stored in the cache folder. This happens at time of schedule creation or every time you refresh the schedule.

CRD uses the cached copy of the report, not the actual source report, when it is exporting scheduled reports and previewing. So yes, you cannot expect the scheduler to be able to access the cached report if you are holding it open in an editor session on another machine.

If you set the cache folder on the client to another path, then schedules that you set up will not be accessible to the scheduler as they will not be cached in the scheduler's cache folder.

I would imagine that the easiest thing to do is to accept that you should not preview the report using CRD at a time when you expect the scheduler to schedule it out. Preview the source report in CRD.

Alternatively, and this is what I do, I run two sessions of CRD which are totally independent of each other. I set up my schedules etc on my test machine which houses a scheduler and an editor.

In the latest build of CRD, it is possible to export a schedule from one installation to another, so I simply use that facility to migrate my schedule accross to the production server once I am happy with it.