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.
There is no possible safe or reliable or smooth way of ever sharing a monolithic Access file with both data tables and UI objects (forms/reports/etc.) in it.

So, first off, the app MUST BE SPLIT.

You can't get around this. You won't be able to ever enhance their app unless you do all your work at midnight when nobody is in the file working.

Secondly, once it's split, every user should get an individual copy of the front end, since sharing a front end is not just a blocking condition for making alterations to it, but also very easily leads to corruption of the front end (which means nobody can work).

It is your job as outside consultant to fix their problems. You have to educate them on what they are doing wrong. You claim it's been working for them, but it's obviously *not* working, or you'd be able to create the new reports for them. Since you can't IT'S NOT WORKING.

The other thing they need to be told:

Whoever implemented it the way it is now WAS DOING IT WRONG.

I've been developing in Access since 1996, and I've never even onced distributed a production app in anything but a split architecture with a front end on each workstation. That was the right way to do it in 1996 (with Access 2) and it's even more the right way to do it post-Access 2000 (when the monolithic Access project was introduced that prohibited edits to front end objects except when the designer had exclusive access).

So, they have to change or you'll not be able to do your work.

You can also point out that they were in a very dangerous and precarious situation where any number of things could have easily gone wrong and corrupted the front end at any time and forced everyone out of the application. 

If they don't want to hear it, then say "thank you very much -- good luck finding someone else to do the job" and run as fast as you can out the door. If you don't, and you acquiesce to their unreasonable requirements, you'll get the blame if it doesn't work the way they think it should.

Do you really want things to go that bad? I guarantee they will if you don't switch them over to the proper architecture right now.