You need the Access Developer / Office Developer Kit or Office/Access Professional (it all depends on which version of Access you have as Microsoft keeps changing its name!)
This kit will give you the Access run-time version which allows you to run an Access database with having to have Access installed. Its a bit of a cheat really as you get to install the full version of Access, but with everything disabled (and cannot be enabled). You need to make sure you have some good error handling in your database as when it falls over it brings the user back to Windows with no warnings.
you also need to be careful with the libraries / DLL's / references you use as these need incorporating into the runtime build. If you don't specify the same references in the run time then the results are unpredicatable and can cuase some very odd errors.
This application was originally written in Access 2.0. I have converted it to Access 2000 and added several modules. I have put it on 5 different pc's and it seems that the references that are being used work sometimes and sometimes they don't. I thought that if I compile it as a stand-alone, that it would act consistent.
If I include all of the references when I compile it, does that sound like the best solution? There are different versions of MS Office amongst the 40 potiential users of this application and I don't feel comfortable after seeing some of the inconsistencies with the 5 I am testing on.
It shouldn't be a problem, It was just a "heads up" tha tyou must ensure the references are properly defined and the correct versions. The runtime environment can have problems with similar libraries to the one yoiu developed with and it can have problems.
The main advantage of using the runtime version is cost. You don't have to but the 40+ copies of Access you seem to need. But you've spent that already. It may be painfull to get the initial users working but thats probably a better solution than trying to wrestle runtime into shape.
Have you consodered updating the various PC's using office update. that probably would shake out many of the support DLL's such as JEt & common controls.
This is a large corporation and on a regular basis, SMS jobs are pushed out to update the large applications such as MS Office and Windows.
In the autoexec macro, I have closed the Form Toolbar so they user doesn't have the ability to get into design view. I don't know what other toolbars could be open on the individual versions of Access. I would like to have the toolbars locked down.
So you think I'm better off running the application from Access rather than compiling it?
Your question started off as I want to use runtime - the normal reaon for using runtime is licensing, or costs thereof
It then became apparent that you had a versioning issue.
There are alterantives to deploying a runtime version of your applciation, such as deploying an MDE variant. Neither is straightforward, both have plusses and minuses.
If your concern is that you don't want users to meddle or access the data in unexpected ways then and MDE or runtime solution is viable. deploying as an MDB is not.
Neither is to be taken on lightly.to get he best the require careful planning and execution.
Locking down toolbars isn't neccesarily the panacea, you can occasionally reduce the functionality of Access requiring more coding effort by tying down toolbars. To a certain extent it depend on your assesment of the userbases's responsibilty. You can get very paranoid locking evrything down to the nth degree, whgen in all probability you don't actually need to.