UtterAccess.com
X   Site Message
(Message will auto close in 2 seconds)

Welcome to UtterAccess! Please ( Login   or   Register )

Custom Search
2 Pages V  1 2 >  (Go to first unread post)
   Reply to this topicStart new topic
> Access 2016 Security, Access 2016    
 
   
AccessWonderKid
post Jun 29 2018, 08:33 AM
Post#1



Posts: 9
Joined: 29-June 18



What is the best way to setup some Access 2016 security in order to prevent the viewing and deletion of forms, reports, tables, queries, etc.?
Go to the top of the page
 
JonSmith
post Jun 29 2018, 08:34 AM
Post#2


UtterAccess VIP
Posts: 4,053
Joined: 19-October 10



Deploy your FE as a compiled file, even better change the extension after compiling from .accde to .accdr
Go to the top of the page
 
GroverParkGeorge
post Jun 29 2018, 08:45 AM
Post#3


UA Admin
Posts: 36,033
Joined: 20-June 02
From: Newcastle, WA


Welcome to UtterAccess.

I assume by " … prevent the viewing and deletion of forms, reports, tables, queries, etc.?" you mean viewing design view, do you not?


Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 08:54 AM
Post#4



Posts: 9
Joined: 29-June 18



Thanks for responding GroverParkGeorge. What is happening is that I have some problem user who is deleting objects such as forms and reports.
This post has been edited by AccessWonderKid: Jun 29 2018, 08:57 AM
Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 08:56 AM
Post#5



Posts: 9
Joined: 29-June 18



Thanks for responding JonSmith. How do you compile the file?
This post has been edited by AccessWonderKid: Jun 29 2018, 08:58 AM
Go to the top of the page
 
GroverParkGeorge
post Jun 29 2018, 09:02 AM
Post#6


UA Admin
Posts: 36,033
Joined: 20-June 02
From: Newcastle, WA


Here's another EXCELLENT way to manage your Access database application.

Split the database into a Front End, containing only the interface objects. This means, forms, reports, queries, etc. and a Back End, containing only the tables.

Link the Front End to the Back End.

Place the Back End in a shared folder to which ALL users have read/write/delete permissions.

COmpile te FE ONLY into an accde, as Jon says.
Attached File  makeanaccde.jpg ( 90.23K )Number of downloads: 16


Give each user their own, personal, COPY of the master Front End accde. Place that FE on their computer, not on a shared folder location.

Keep the orginal accdb and the original accde in a safe location only you control.

If one of them trashes their own copy, too bad, so sad. Give them a fresh copy and tell them to be more careful.
This post has been edited by GroverParkGeorge: Jun 29 2018, 09:03 AM
Go to the top of the page
 
JonSmith
post Jun 29 2018, 09:04 AM
Post#7


UtterAccess VIP
Posts: 4,053
Joined: 19-October 10



Go to the Backstage tab (File) and go to save, there you will see a bunch of different file types, among them is 'Make ACCDE - File will be compiled into an executable only file.'

Note, this is a one way process, you cannot uncompile the .accde back into a .accdb and make any kind of design changes. Do not lose your .accdb copy as you need it for any changes in the future.

JS

Edit: George beat me to it.

QUOTE
Split the database into a Front End, containing only the interface objects. This means, forms, reports, queries, etc. and a Back End, containing only the tables.

Link the Front End to the Back End.


I was assuming a FE BE setup, if your database isn't split, stop, now. No really. Go split your database now, it will be so much trouble if you don't.
This post has been edited by JonSmith: Jun 29 2018, 09:05 AM
Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 09:07 AM
Post#8



Posts: 9
Joined: 29-June 18



Thanks for the response GroverParkGeorge. So to compile the FE to an ACCDE, I simply perform a Save As, select Make ACCDE, as Save As? Is that correct?
Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 09:12 AM
Post#9



Posts: 9
Joined: 29-June 18



Thanks for the information JonSmith. I appreciate the help. I am going to split my database into the BE for tables and FE for everything else.
Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 09:13 AM
Post#10



Posts: 9
Joined: 29-June 18



What is the advantage of making the front end an ACCDE executable only file? If I split the database, but don't convert the FE to an ACCDE file, what issues does this cause?
Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 09:18 AM
Post#11



Posts: 9
Joined: 29-June 18



What is the easiest way to split the database? Do I simply make copies of the database and delete everything but the tables from the BE and then in a second FE copy delete the tables and relink to the BE tables?
Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 09:42 AM
Post#12



Posts: 9
Joined: 29-June 18



I have split my database into a BE and FE; however, it will not allow me to convert my FE into an ACCDE version. Do you have any idea why it won't convert my FE into an ACCDE version?
Go to the top of the page
 
JonSmith
post Jun 29 2018, 09:55 AM
Post#13


UtterAccess VIP
Posts: 4,053
Joined: 19-October 10



So the advantages are numerous, for one you significantly reduce the chance of corruption and your app tanking.
Another is its much easier to push updates as you can mess around with the forms and code and replace the FE whilst leaving the data intact.
It goes on and on.

The likely reason you cannot make an .accde is because of sloppy coding mistakes that prevent the code compiling.
Add Option Explicit to the top of every module and in the VBA editor compile the code from the debug menu (this is a different kind of compile than the .accde), it will highlight all the places where there are mistakes or issues.
Once you fix all of them you should be able to make a .accde.

Go to the top of the page
 
theDBguy
post Jun 29 2018, 10:08 AM
Post#14


Access Wiki and Forums Moderator
Posts: 76,548
Joined: 19-June 07
From: SunnySandyEggo


Hello,

Pardon me for jumping in... I just wanted to say:

Welcome to UtterAccess!
welcome2UA.gif

One thing I haven't seen mentioned, unless I totally missed it, is after you have split the database and placed the BE in a safe location, maybe consider using a script (Jon has one he could probably share) to always download a fresh copy of the FE each time the user runs the app. This way, they can mess with their copy as much as they like; but the next time they open it, they'll get what you originally gave them. Side effect: all their changes will be gone.

Just my 2 cents...
Go to the top of the page
 
isladogs
post Jun 29 2018, 10:45 AM
Post#15


UtterAccess VIP
Posts: 1,795
Joined: 4-June 18
From: Somerset, UK


In addition to splitting the database & converting the frontend to ACCDE, I would also strongly recommend hiding the navigation pane & ribbon (AFAIK nobody has mentioned this so far).

This means users will only be able to access database objects via forms & reports which is how it should be
That should make it almost impossible to delete anything.

By all means rename to ACCDR as well but do remember users can reverse that change - if so use code such as jon's to protect it (or other similar variations)

I stressed 'almost' impossible - a determined and skillful hacker can break any Access database given sufficient time.
What the above suggestions are doing is providing security to cover almost all situations
Go to the top of the page
 
GroverParkGeorge
post Jun 29 2018, 10:48 AM
Post#16


UA Admin
Posts: 36,033
Joined: 20-June 02
From: Newcastle, WA


Actually, for a moderately knowledgeable person, exposing the navigation pane is almost trivial, as is bypassing start up code.

IMO, those steps fall under the category of "making it pretty", not under "security".

Go to the top of the page
 
isladogs
post Jun 29 2018, 12:57 PM
Post#17


UtterAccess VIP
Posts: 1,795
Joined: 4-June 18
From: Somerset, UK


QUOTE
Actually, for a moderately knowledgeable person, exposing the navigation pane is almost trivial, as is bypassing start up code.

IMO, those steps fall under the category of "making it pretty", not under "security".


George
If that's all I was recommending I would agree with you.
But it wasn't and I don't.

In conjunction with all the other measures suggested in my post & all the above posts (which is what I meant before), it is another level of security
But I'll repeat what I said before - no Access database can ever be made 100% secure.
Go to the top of the page
 
AccessWonderKid
post Jun 29 2018, 02:24 PM
Post#18



Posts: 9
Joined: 29-June 18



I want to greatly thank everyone for their help and feedback on my questions. It has been very helpful and extremely appreciated! Thanks again and have a great weekend!
Go to the top of the page
 
GroverParkGeorge
post Jun 29 2018, 05:51 PM
Post#19


UA Admin
Posts: 36,033
Joined: 20-June 02
From: Newcastle, WA


Thanks for the clarification, but I'll repeat, unhiding the nav pane is to easy to call it "security". It's better than nothing, of course. I just don't feel people should be encouraged to think of it as part of a security package.
Go to the top of the page
 
isladogs
post Jun 29 2018, 06:23 PM
Post#20


UtterAccess VIP
Posts: 1,795
Joined: 4-June 18
From: Somerset, UK


OK - since we disagree, I'll knock up an example database as a challenge in the next couple of days.
I'll put it in a new thread & call the thread GroverParkGeorge Challenge or similar.

It will contain a number of hidden tables - the challenge will be to obtain the table names, number of records & the contents of one record in a specified table.
Sounds too easy I know....but there will be a twist to make it a bit trickier!

Go to the top of the page
 
2 Pages V  1 2 >


Custom Search


RSSSearch   Top   Lo-Fi    15th November 2019 - 12:38 AM