When you first split, both the front end, and the back end mdb files are in
the same directory.
If you move the location of the back end, then you need to re-link.
The re-link process is done via the linked table manager.
So, all you do is move/place your back end to where ever. You then will have
to re-link
And, of course if you are still doing on-going development, then you have to
add tables to the back end. Exit the back end,a and then in the front end
simply go new->Table, and then choose "link". So, you can actually link/add
ONE table at a time if you wish.
For a97, you will find the linked table manager in
Tools->Add-ins->Linked Table Manager
For a2000 and beyond, is found:
tools->Database Utilities->Linked table Manager
Of course, if you are getting ready for a multi-user setup, you probably
should distribute a mde file to each user. A mde file is a "production" copy
for your users, and your users CAN NOT modify, or change this copy. You then
keep the original mdb, and continue to work on your next great version.
You sit down and play, work, learn, and become familiar with this linking
process, as it is going to be a normal part of your development process.
Here is some further reading on this process:
http://www.granite.ab.ca/access/splitapp.htm
http://www.microsoft.com/accessdev/articles/bapp97/chapters/ba15_3.htm
As for security, hum, I would probably secure before. But, it really don't
matter. If you have not added a whole bunch of table permissions, and are
only setting permissions for forms, reports, then it really don't matter. If
you have not setup a whole bunch of security stuff yet, then I would just
split, and setup security later.
Remember, all the user logons, groups, passwords stuff is in ONE workgroup
file, and does NOT exist in the mdb file. So, the one workgroup file applies
to ALL databases. So, user's workgroups and passwords stuff is in the
workgroup file, and will apply to both the front end, and the back end (or
for any database that the user opens while joined to that particular
workgroup file). No user permissions belong in the database files, but only
in the workgroup file. The only permissions that you should have in each
database is what "group" a form, report etc belongs to. Using this approach
means you can safely update the users to a "new" front end, and NOT loose
any security settings that the customer might change (it also means you can
develop off site, and send updates). If you do start placing actual users
permissions in a database, then you create a real mess.
