shift override in split database

[inbreda]

Hi

I have a split database, both parts (FE and BE) have been copied to provide
a development database. Both use the same workgroup file.

When I further develop the database and try to distribute it for live use,
all of the security groups and access rights change, so I have to spend
several hours reinstating them every time. How can I stop this.

Also, I went to great lengths to secure my database. The FE is an mde file,
and there is a button on a form that only the administrator can get to that
will disable the shift over ride. Because it is a multi user db, I took
advice on how to split it into a FE and BE (i.e. don't use the database
splitter functionality in Access) and this has left me with a BE that only
contains tables and is completely exposed. How do I stop people from opening
the BE and viewing the data?

 

[Keith Wilby]

Hi

I have a split database, both parts (FE and BE) have been copied to
provide
a development database. Both use the same workgroup file.

When I further develop the database and try to distribute it for live use,
all of the security groups and access rights change, so I have to spend
several hours reinstating them every time. How can I stop this.

Can you expand on what you mean by this? It would seem that you may have
missed a step in the securiing process.

Also, I went to great lengths to secure my database. The FE is an mde
file,
and there is a button on a form that only the administrator can get to
that
will disable the shift over ride. Because it is a multi user db, I took
advice on how to split it into a FE and BE (i.e. don't use the database
splitter functionality in Access) and this has left me with a BE that only
contains tables and is completely exposed. How do I stop people from
opening
the BE and viewing the data?

You need to remove rights to the users group.

Have you read the MS FAQ on Access security? There's a link to it on my web
site. In short, it's essential reading and once you fully understand it
then you'll be able to correct the problems you describe. It's one steep
learning curve and there's no filler in it but there's no substitute for it
either.

Good luck with your project.

Keith.
www.keithwilby.com

 

[inbreda]

I started with a database that is opened using a shortcut, and uses an .mdw
file. The mdw security is fine. User and admin accounts have no permissions.

Depending what user group the user belongs to dictates what tables and forms
they can open/delete/update etc.

The database was then split into FE forms/reports etc and a BE data source.
This is my live database.

I then copied the live FE and BE to use for development (DFE and DBE). This
development database uses the same mdw file. Password restricted access still
works.

Once I've done some development work on the DFE and tested it thoroughly
against DBE data, I overwrite the live FE with the development DFE. I then
delete the table links (which of course still point to DBE) and then recreate
table links to the live BE, so my users can continue using the database and
access the same data they were previously using. I expect to do this piece of
work, however the database no longer works properly. This is because the user
group permissions have all been reset, so I have to go into
tools>security>user and group permissions, and reassign all of the
tables/forms/reports that each security group is allowed to
open/modify/update/delete/insert. This takes a LONG time and annoys me
because all of the permissions on the FE, BE, DFE and DBE should all be the
same.

Is there something I can do to avoid resetting all these permissions every
time I release a new version of the database?





The second part of my question regards shift override. When I release a new
version of the FE (i.e. when I overwrite live FE with DFE) I make it an mde
file and disable the shift override of startup options (by clicking a
specially placed hidden button on a form that only the admin user can reach).
This succesfully prevents users from overriding the startup options ... but
only on the FE. The BE with all of the important data in can still be opened,
and all tables that the user has read permission for can be viewed. This
really isn't very secure, but removing access rights will surely prevent
forms in the FE from working properly?

Cheers.

 

[Joan Wild]

The database was then split into FE forms/reports etc and a BE data
source. This is my live database.

When you split it did you use the splitter wizard? That will result in an
unsecure BE.

This is because the user group
permissions have all been reset, so I have to go into
tools>security>user and group permissions, and reassign all of the
tables/forms/reports that each security group is allowed to
open/modify/update/delete/insert.

This will happen if you import any objects - permissions do not travel with
the objects.

The BE with
all of the important data in can still be opened, and all tables that
the user has read permission for can be viewed. This really isn't
very secure, but removing access rights will surely prevent forms in
the FE from working properly?

You can disable the shiftkey bypass in the BE as well. Put an autoexec
macro in it that displays a message and closes the database.

In addition you can remove all permissions on the backend tables, and use
RWOP (run with owner permission) queries in the FE for all data interaction.

 

[inbreda]

No I didn't split it using the wizard. I copied the database and called one
FE, and the other BE, and then linked the tables.

Although p[ermissions do not travel with tables I was surprised as the
permissions should be the same on hte BE, FE and development FE and
development BE... but it still resets all of the permissions and costs me
time in resetting everything every time I re-release a database. Another
Access annoyance!!!

 

[Joan Wild]

I have never seen or heard of this.

--
Joan Wild
Microsoft Access MVP

No I didn't split it using the wizard. I copied the database and
called one FE, and the other BE, and then linked the tables.

Although p[ermissions do not travel with tables I was surprised as the
permissions should be the same on hte BE, FE and development FE and
development BE... but it still resets all of the permissions and
costs me time in resetting everything every time I re-release a
database. Another Access annoyance!!!

When you split it did you use the splitter wizard? That will result
in an unsecure BE.


This will happen if you import any objects - permissions do not
travel with the objects.


You can disable the shiftkey bypass in the BE as well. Put an
autoexec macro in it that displays a message and closes the database.

In addition you can remove all permissions on the backend tables,
and use RWOP (run with owner permission) queries in the FE for all
data interaction.