Home All Groups Group Topic Archive Search About

shift override in split database

Author
1 Aug 2006 2:55 PM
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?

Author
1 Aug 2006 3:50 PM
Keith Wilby
"inbreda" <inbr***@discussions.microsoft.com> wrote in message
news:A7FFA005-0446-4D87-9C5B-2BCF677028FB@microsoft.com...
> 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
Author
13 Aug 2006 3:33 PM
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.

Show quoteHide quote
"Keith Wilby" wrote:

> "inbreda" <inbr***@discussions.microsoft.com> wrote in message
> news:A7FFA005-0446-4D87-9C5B-2BCF677028FB@microsoft.com...
> > 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
>
>
>
Author
13 Aug 2006 7:35 PM
Joan Wild
inbreda wrote:
> 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.


--
Joan Wild
Microsoft Access MVP
Author
14 Aug 2006 1:20 PM
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!!!

Show quoteHide quote
"Joan Wild" wrote:

> inbreda wrote:
> > 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.
>
>
> --
> Joan Wild
> Microsoft Access MVP
>
>
>
Author
14 Aug 2006 3:00 PM
Joan Wild
I have never seen or heard of this.

--
Joan Wild
Microsoft Access MVP

inbreda wrote:
Show quoteHide quote
> 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" wrote:
>
>> inbreda wrote:
>>> 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.
>>
>>
>> --
>> Joan Wild
>> Microsoft Access MVP