I've been developing an Access 2010 Database Application, let's call it Skill.accdb
.
I'm at the stage where I want to start deploying it so users can start using it and continue developing at the same time.
I've been reading
- MSAccess-Deployment-Best-Practices,
- Deploy-an-Access-2007-application, and
- Ways-to-share-an-Access-database
which talk about splitting, compiling, installing, etc., but they're very short on actual procedural steps to follow.
I have split my database application into a back-end and a front-end: Skill_Back.accdb
and Skill_Front.accdb
.
The back-end is on a network shared drive and some users have copies of the front-end.
So far so good, especially if I never have to do any more development.
But I can't quite see how to now continue development on the front-end without disturbing the "live" back-end.
How do I have a development version of the front-end pointing to a dummy version of the back-end so that I don't mess up the live version? And then, when I wish to release a new version of the front-end, how do I get it to point again to the live version of the back-end?
If I re-split (ie, use the Move Data | Access Database tool again) to point to a not-yet-existing dummy back-end, I'm told all the tables are now empty -- not what I want. If I re-split to point to a copy of the live back-end, I'm asked if I want to replace it -- also not what I want. If I do, again I'm told "There are no tables in this database. The back-end database will be empty." and yet I see that it (the front-end) is still pointing to the live back-end!
What critical concept/tool/procedure am I missing? (I'm not asking about compiling or runtime or building an installer -- those are later problems.)
addendum
Further to following the advice in the fine answer below, I found a couple of other articles that do describe procedures:
This isn't a website, or a file; it's a database. You can't update every copy of your front end on each user's computer, it just doesn't work that way.
A strategy I use is to "version" my front-ends, and when I deal with databases I don't uses Access' built-in
Move Data
tool.You need (at minimum) 2 different environments
For Testing, you need your own back-end and front-end. This is where you will do your continuous development. You never want to disturb what your users are working with, especially the data.
For production, you can make your changes and roll out the new version via shared network drive where the users can download the copy, much like the first one. This is where you'll use the
Linked Table Manager
to reconnect the tables to your production back-end and your new front-end.So the work flow would be:
Linked Table Manager
.Linked Table Manager
In the Navigation Pane, right-click one of the linked tables to open the shortcut menu. From there, choose Linked Table Manager.
That makes it easy to manage the links. Put a checkmark in the box next to each linked table you want to change. Or if changing them all, click Select ALL. Also check the box labeled "Always prompt for new location" (at the lower left corner of that dialog window). Then Access will ask you to locate the database source for the links.
If you need more info just say something.
Linking New Tables from Back End to Front End
If I have a back-end database with tables and I wanted to link those tables to a front-end on my desktop, I would follow this process:
Link to the data source by creating a linked table.
Now you will see the tables in your front end. You can then use the Linked Table Manager to manage these links should, for example, your back end database be moved to a different location.