Access 2021 compiled for accde file (1 Viewer)

[Kingz]

Hi,
I thought an accde file, wouldn't give the user access to the tables and queries, but I don't see any difference to the developing file.
I remember in the older versions you could create an exe for the user. How close can I get to that? I would like it to start with my form frmMain, and the user should have no access to the tables and queries.

 

[gemma-the-husky]

By default a use can see tables and queries, and edit them. They can't edit forms reports or modules though.

Sometimes it's useful. If you want to prevent access, you need to hide the database window.

 

[Minty]

I remember in the older versions you could create an exe for the user.

Not that I can remember. There has never been a inbuilt method to create an .exe in Access.
Have a read here for how to secure your database:

Compare Access File Security

This article compares the security of the MDB & ACCDB file formats together with the compiled MDE & ACCDE versions.

isladogs.co.uk

 

[theDBguy]

ACCDE doesn't prevent access to tables and queries, only design view or forms and reports and code window. How Access savvy are your users?

 

[isladogs]

Hi,
I thought an accde file, wouldn't give the user access to the tables and queries, but I don't see any difference to the developing file.
I remember in the older versions you could create an exe for the user. How close can I get to that? I would like it to start with my form frmMain, and the user should have no access to the tables and queries.

As well as the link provided by @Minty, see these other two articles of mine:

Improve Access Security 2

This article explains how to apply various security measures to make your databases as secure as possible. An example app is used to illustrate the possible methods available

www.isladogs.co.uk

Lock Down Database Objects

End users should only view data using forms. However, knowledgeable users may know how to circumvent basic security and access/edit/delete data from tables. This article demonstrates one way of protecting all database objects from unwanted modification. The example app prevents users opening...

www.isladogs.co.uk

 

[Pat Hartman]

I remember in the older versions you could create an exe for the user

That was only to distribute the file. You could never run the app from the .exe. Running the .exe unpacked the database.

.accde only hides the code. A simple trick is to rename the .accde to .accdr. That tells Access to pretend to be the runtime engine. This might break things in the app since it hides the Access ribbon and right click menus so you might have to add features to replace the ones that disappear. @isladogs has created great documentation on his website to help you to lock down your apps.

 

[Kingz]

First of all, thanks for all the information!
I'm left with a very confused frame of mind now however.

Let me maybe elaborate on what I want to do, because there seems to be a few paths, where I'm confused as to which path to go on, especially after reading "lock down database objects".
I have a working application which starts with a main form allowing other forms to be opened. In these forms, the user can edit and save data, which is kept in tables. In fact the main edited table will be centrally kept in it's own mdb file, where all users using the application have access. This way several people can use the application, and the tables are centralised.

So because the application is doing the editing and saving, I don't want the user to be able to access the tables and queries. I just want the user to start with the main form and use it like any application, without delving nosily into the dB structure. What is the easiest way for me to accomplish this?

 

[arnelgp]

use an .accdr (runtime).

 

[gemma-the-husky]

You could tell the users to only use forms to enter data, and not to use tables directly.

In my experience, users won't try to interfere with data, especially if they know how important it is.

You can restrict access to the tables in ways explained by others in the thread.

Using an accdr is a bit drastic, as you will need to write code to do the many things that you have removed from the users environment. You also might need to add code to make sure they don't just rename the accdr back to accde.

 

[GPGeorge]

First of all, thanks for all the information!
I'm left with a very confused frame of mind now however.

Let me maybe elaborate on what I want to do, because there seems to be a few paths, where I'm confused as to which path to go on, especially after reading "lock down database objects".
I have a working application which starts with a main form allowing other forms to be opened. In these forms, the user can edit and save data, which is kept in tables. In fact the main edited table will be centrally kept in it's own mdb file, where all users using the application have access. This way several people can use the application, and the tables are centralised.

So because the application is doing the editing and saving, I don't want the user to be able to access the tables and queries. I just want the user to start with the main form and use it like any application, without delving nosily into the dB structure. What is the easiest way for me to accomplish this?

The most comprehensive information about security in Access I know is the set of articles on Isladogs' website. Those references have already posted in this thread.

The bottom line is this. If you absolutely can't tolerate any risk whatsoever that users might, even if only inadvertently, and by accident, see the tables directly, then Access is the wrong tool for this project.

I once worked at a company where a senior VP liked to remind people that, in her opinion, most employees come to work thinking of ways to impress their boss and earn a raise or a promotion. Almost no one comes to work thinking of ways to screw up and get fired that day.

Explain to people what your expectations are and then trust them to do it right. You'll waste fewer hours of your own time trying to think up new ways to control their every action, and if someone does betray you, take action then.

 

[Kingz]

Ok, I seem to have a simple solution:

In before_update() I set cancel= true. That works.. The only thing is, I need to surpress the message "you can not save this dataset currently... Do you still want to close the database object (yes /no)" , when I close the form.. Any ideas how to surpress this?

 

[The_Doc_Man]

If you don't want to save things before you close, perform an UNDO operation first, then close. If there is nothing to save, Access will be silent.

 

[gemma-the-husky]

The most comprehensive information about security in Access I know is the set of articles on Isladogs' website. Those references have already posted in this thread.

The bottom line is this. If you absolutely can't tolerate any risk whatsoever that users might, even if only inadvertently, and by accident, see the tables directly, then Access is the wrong tool for this project.

I once worked at a company where a senior VP liked to remind people that, in her opinion, most employees come to work thinking of ways to impress their boss and earn a raise or a promotion. Almost no one comes to work thinking of ways to screw up and get fired that day.

Explain to people what your expectations are and then trust them to do it right. You'll waste fewer hours of your own time trying to think up new ways to control their every action, and if someone does betray you, take action then.

I think the last points you make are on point.

I think a bigger problem is being aware than an access database is easy to copy, and your data may not be as private as you would like it to be. That may be a real issue as databases will most likely hold sensitive information.

 

[Gasman]

I never mentioned anything about SQL? I was just suggesting Cancel = True until you press the save button, but use the normal code that would be in the BeforeUpdate event.