Question: Does anybody know if there is a way to generate reports in Access "in memory" where the report doesnt need to be written to the Reports collection? I'm having issues with concurrent users - if the user doesnt have "exclusive access" to the access application the report generation fails, because it requires the previous report to be deleted, which it won't allow. I've looked at the CreateReport method, and I'm not sure if it can accomplish what I'm looking for. 

//edited **The templates referenced dont allow any controls(labels, textbotes,etc)**  

The help information associated with the method mentions report templates as well, but I'm not sure if those are some other type of object or just a pre-designed report that you can use as a template.

Anyways before I start banging my head up against it trying to make it work I was wondering if anybody had used the CreateReport method before or whether there was some other functionality/design that I'm overlooking.

Answer: 
You need to setup your application like most every other application your organization deploys. That means you place the software application on each computer. So, when you want to use a program like word, you install it on each work station. And, when you want to use a program like Excel, you install it on each work station. That way, if one person in your organize has a program with word, it don't impact everyone in the company and they all go home while the one person's problem is fixed.

The exact same advice applies with Access. You are now using a development tool that builds software, and like any other program; you install this program on EACH work station. Everyone quite much worked this way in our industry for 20+ years. It is possible that you don't understand the difference between a data file (that word, or Excel or your program) can consume, and that of an application with a UI and code that runs. That program part has traditionally been placed on each computer to isolate programs.

Can you imagine one person having a problem with Excel and everyone else has to go home while that is fixed? Do the same with your software, and the fact that you are writing your own in house software as opposed to purchasing is not an excuse to ignore how you have been deploying all of your other software. I explain the simple process of splitting here:

<http://www.members.shaw.ca/AlbertKallal/Articles/split/index.htm>

Do the above not only improves reliability, but it also means you can develop on a copy of the next great release of your application while users are working and using the current version. Splitting takes less time then it takes to write this post, and is really much a requirement the instant you deploy code to more then one user.
Most Access apps use two access files: a program one and a db one. The db one contains the data, and each user has a copy of the program one with the tables attached. Reports can then be created in the program's mdb/mde without affecting other users.

If you're using a single file model, then as a workaround, what about generating new reports each time using the user's ID (eg 1234\_MonthlyReport) and cleaning them up on exit?