Secret Squirrel said:
I have 2 questions regarding database splitting and permissions..
1. If I had a split database on a server and then copied both the FE & BE
to
my local hard drive would I have to refresh the links between the two or
will
they stay intact? I don't mean will they keep the links to the FE/BE on
the
server but if I was to open the FE on my local hard drive would it
automatically keep the links to the BE on my local hard drive?
The links never change. so, if you copy or move the front end, the links
will
ALWAYS point to the same location. So, caution has to exercised here..
I once had a client where some of the front ends where pointing different
back ends.
The results was a real nasty situation, as then we had data entered into two
different back ends, and reconcile them is VERY hard indeed...especially
when you have a application with 50+ highly related tables....
So, no, just copying around a file in no way is going to make ms-access go
on a re-link binge all on its own....
So, one of the GREAT benefits of a split system is that while developing, I
have both a copy of the front end, and back end on my pc. I am free to test
dangerous update, or deleting routines with any fear at all. When I am
finally happy with my next great version, I link to the production back end
(and, I use unc path names...so, drive mapping will NOT matter). After I
link to the correct back end, I then create the mde file which will be
distributed to each pc. My update routine is built into the software. Here
is a few screen shots of what this process looks like
http://www.kallal.ca/ridestutorialp/upgrade.html
2. Are all the permissions kept in the .mdw file or are they kept within
the
database itself? What information is stored in the .mdw other than user
names
and passwords?
User names, passwords, and what security groups each user belongs to is
saved.
Of course, if you don't create, or use any security groups..then there are
no security groups!!
If you have no security groups to assign forms to, then you will be forced
to assign forms, reports
etc. to individual users..and you do NOT want to do this!!
So, all of the passwords, and what security "groups" a user belongs to is
contained in the workgroup file. You ALWAYS must be joined to a workgroup
file BEFORE you open and use a application (or data file). So, you log on to
ms-access, enter your password, and then you can OPEN THE application.
After logon, you THEN can open any data file. ...and that includes linked
mdb files..but, the passwords, and what groups you belong to is contained in
the SINGLE workgroup file.
If you secured your database correctly, then any user who is not logged into
the CORRECT workgroup will NOT be able to open the front end, or back
end..or any secured mdb anywhere on your computer unless they are logged
into the correct security workgroup.
This is also why you likely will have the workgrup file in the same directly
as the back end mdb file. (since then you only have one workgroup file with
user names and passwords).
Now, of course permissions of what forms and what reports etc. is contained
in the application. If you do a real bone head move, and actually start
assign forms, or reports to users in place of security groups, then you ARE
placing permissions in the database for particular users. The end result of
this is if you issue a update to your software, these permissions changes
WILL BE LOST!!! This would make it near impossible to issue updates to your
software. Especially if you desire to have many clients/customers using your
software!!1 (and, I think we all want that!!!).
So, when you ask are some of the permissions for users kept in the database,
well, the answer is only if you are fool will this be the case. Simply put,
NEVER assign forms to a particular user (as that is contained in the
database). But, ALWAYS assign forms, reports etc. to security groups in the
application. Of course, those security groups are also in the application,
but they will also be in your workgroup file. This will thus keep out any
individual user permissions from your applications.
Of course, what this means that is you need to sit down, and build a few
security groups.. You customer, or users of your application will most
certainly assign what users belong to what security group. This kind of
means that you don't let your users create any security groups, but you do
this for them. Most of the time this works quite well.
You can see some screen shots of how I add new users here:
http://www.members.shaw.ca/AlbertKallal/Articles/UseAbility/UserFriendly.htm
In the above, you can see a security screen where I display the "secirty
groups" in a list box..and you just highlight which ones you want..the code
behind adds the users to that security group.
