Distribution of a database: Splitting and Runtime (1 Viewer)

Hello,

I would appreciate any and all thoughts about the best way to distribute a database to non-Access users (our office does not have general licenses for Access--I am using a standalone copy of 2007 that I convinced the office manager to purchase for me).

As of now, I plan on distributing my database to coworkers via Runtime.

I am curious to know if it possible to split a database that will be running on Runtime. If so, can someone give me a general sense of how would this work? I would like to split for various reasons the biggest being that I want to be able to make changes to the front-end as needed.

Or is there a better way?

I really appreciate any insight you may have about this.

Thank you!

The Runtime version will run the database just as the full version does only there will be limited functionality. With regards to splitting the database this is highly recommended. After this you will need to either distribute users with their own front end or give them a link to a shared front end. The other thing is to make sure each user can see the same path as the linked front and back file as they won't be able re-link the tables in Runtime.

The best solution is always to split. Using the Runtime engine doesn't alter that. The runtime engine is simply MSAccess.exe that has been crippled so that it can't show anything in design view. Your app needs to be completely controllable by using forms. The user can never get to the navigation pane. You may also need to create custom ribbons since you are using A2007.

I don't know if the runtime for A2007 is still available. If it isn't, you can probably use the A2010 runtime. I wouldn't go with A2013 unless you are certain that you are not using something that has been deprecated.

Start with your .accdb.
1. Make a backup and zip it.
2. Split the database either using the built in splitter or manually.
3. Move the BE to the network share where it will reside.
4. Relink the FE to the share - use UNC naming rather than a hard-coded drive letter. It is more flexible and doesn't require everyone to have the "M:" drive mapped the same way.
5. Make another backup. This time of both the FE and BE and zip it. I always zip my backups because it is harder to use them by mistake that way.
6. Create an .accde from the FE.
7. Rename the .accde to .accdr. This isn't strictly necessary but if any of your users get a full retail version of Access in the future, this extension tells Access to pretend to be the runtime engine even if it isn't. The .accdr trick is also a way for you to test out how the app will behave under the runtime even though you have the full version installed.
8. Give each user his own personal copy of the FE and have him load it on his "C:" drive. Don't use a network drive since that just adds overhead. Although. I have one client with a mixed environment that prevents me from using a normal FE loader to give them new versions so for them, I created separate folders for each person on a shared drive and put a copy of the FE in each person's share. This keeps me from having to visit each computer to install a new version. I just have to put a new copy in their server folder. I'm hoping that in a few months they will standardize their systems and I will be able to get my FE loader to work on all platforms but until then, this works. Sharing a single copy of the FE is poor practice and can lead to corruption.