I am a teaching an IT course to 15 year-olds. Part of the course is an assignment in which we create basic relational databases using Access. I have a beginners level knowledge of Access (it is not my background) and the students are not expected to use VBA (it is far beyond the scope of what we cover in the course).
The examining body has asked the following:
The database will have a table with some basic student data (name, age, exam score etc). We will create a form to view/edit/add etc. But we are then asked to implement some functionality so that one password ("password1") only grants Read-Only access to the system but a second password ("password2") grants full editing rights.
I have seen some very complex solutions to this online, but nothing that is appropriate for the level of students this course is aimed at.
As this is an educational setting we don't need to be overly concerned with the actual integrity of the system (it's just a basic course) and VBA is not an option.
Is there an option that will allow us to have a login screen that takes users that enter one password to a Form with editing options disabled, and if the other password entered they are enabled (and I just hide the table from view... remember this is basic)?
Thanks, sorry for such a basic question... bear in mind this course is being discontinued in 2023 ;)
Since you are not using VBA I assume that you are using macros to open forms, etc.
You can open a form in read-only mode with the action OpenForm by setting the Data Mode to Read Only.
If you want to disable buttons in the form you just opened, you can execute the action SetValue with Item = [Forms]![frmSelect]![cmdSelect].[Enabled] or Item = [Screen].[ActiveForm]![cmdSelect].[Enabled] and Expression = False. (I assume that the form name is frmSelect and the button name cmdSelect.)
The VBA equivalent would be:
DoCmd.OpenForm "frmSelect", DataMode:=acFormReadOnly
Forms!frmSelect!cmdSelect.Enabled = False
In older Access Versions (< 2007) a completely different way is to use the built-in security system (which I don't like). See: How To Manage User Permissions In Access Database?
Related
Intent: I would like to distribute forms to User X, User Y and User Z. These forms would be pre-populated with existing data on their ongoing projects. Meaning for User X, he will only be able to see his own details etc. They are to validate the information, and make changes to the data if necessary.
I tried finding the best way to go about executing this and landed on MS Access (if there's something else, please do share).
So I have a database, created my forms but how do I go about sharing only the forms to my users and updating my database. Resources I have include:
SharePoint Online (may or may not have access to it...)
Outlook
Desktop Access
I am open to various scenarios involving direct updating through SharePoint, or even manually updating the forms received through them via email if it is possible.
My most important consideration is data security. User X should not be able to see the details of other users. User-level security from older versions of Access could probably do that but its no longer in the newer version and a check online suggests it isn't the most secure option.
Any help would be much appreciated.
You do not include any information on what kind of data your "forms" includes why you collect the data and what do you want to do with it. At the very least if data from multiple users needs to be combined for any sort of overall reporting.
If the most important consideration is limiting each user to a sub-set of the data then I don't see how you decided MS Access is your best option. Any security on an Access file is easily bypassed. On top of that unless each of your users has their own set of tables you cannot set up any kind of security that isolates their individual information.
To completely isolate user information you have three options:
Use a separate database for each. Then, if you need to, link them all
into a master database in the back end.
Use an isolated front end. You cannot use an Access front end as that
will have to link to the tables; you have to use a separate
interface, either a web type interface or a Windows application that
the user has to log on and has no access to any data other than what
the software is displaying.
Use import/export files. Have access export each user's info to an
Excel sheet or other convenient data file. Let them make their
changes and return the files to you, then import them back into your
database.
I would appreciate if someone would help me with this.
I am new to Access and my boss has given me a project to create a tool for our team (I work in insurance). I'm done with most part of the project, but my boss wants editing and updating of database restricted to a few members of our team (yes more than one person can modify) but since the tool is to be used for a wide range of purposes, she would like that the rest of the department (50+ people) can only access certain forms which have buttons etc. that do the job.
So far in this database I have, 3 linked tables (which hold all the data), queries, reports, union queries and make tables and 3 forms. What I would like is for most people to only view forms and use it in form view only, but 4 members of my team to do whatever they want since they need to constantly edit the data.
Does anyone have a hint about where I should begin? Programming is not my cup of tea so I would really appreciate some reference etc. or any help!
If you hit file, then hit options, and then select current database, you can force a specific form to pop up whenever you open the access database. In addition, you can take away the user's ability to go through the entire database's content. you can also take away the navigation bar and menus and such. I have been doing this for a while, so here's some advice. Have a main menu form that has a button for every form in the access file. When the user opens the database, he or she should see that main menu form. From there, they can click on the button that will lead them to the form that will solve the needs they have.
Stackoverflow won't let me post a comment, so here is what I was going to say. For those who you want to have access to it, you can have them hold shift while opening the database. If they do that, they will open the database like they were an "admin" to the database. They would be able to edit it however they would like if they hold down shift.
I have done this via a table, assigning users a specific "Security Level" and checking their security level via a login screen. I then hide the login screen (not close it) so that anytime a form is open it can do a DLookup of the user's security level and then determine if the user has read, write or read/write access to the form. I can also hide buttons on the form based on the same logic.
Starting in 2007, Access removed their native security, which was pretty inefficient anyway.
Is it possible to set Access persmissions using Active Directory users?
Edit: The overall objective is to allow some users to see certain tables and deny this permission for other users. I'm wondering if it can be done using active directory users.
Depends on what you mean by Access permissions. Access user level security do not interact with Active Directory in any way. ACC: Microsoft Access Security FAQ Available in Download Center It is suggested you reread this FAQ several times. I must admit I never quite understood it. Also see ACC2000: Overview of How to Secure a Microsoft Access Database
Now what you could do is read the Active Directory data for the logged in user and groups and such. Then with some local tables mapping the various AD groups along with the login userid to the various objects and menu items in Access you could control access in this fashion. Note however that local tables can possibly be mucked with by a savvy user, etc, etc.
The most useful URL I found was the following newsgroup posting need help on get list of W2K ad Domain (fqdn) by using VB Options I kept a page of notes when I was working on this topic but they may or may not be useful. I can post them if desired.
I agree with the things that both Tony and Philippe has posted. I just want to add a bit:
If you really need security, then a Jet/ACE back end is not going to do the job for any significant definition of the word "security". Jet ULS is crackable and fairly easily so for anyone with even basic programming chops. Thus, if it's DATA SECURITY that you're looking form, Philippe is right that you should choose a different database engine.
But if you are only looking to control ACCESS in your front-end application, you have three choices:
maintain a couple of tables in your database of your users and the permissions on each of the objects.
implement Jet user-level security.
use AD users/groups in place of Jet ULS.
None of these choices is seamless.
And all of them mean that your front-end has to be programmed to deal with the issues.
If you're restricting access for security reasons, then it makes sense to use a database engine that integrates with Windows security (i.e., SQL Server).
If you're doing it just to streamline program flow, and to adapt the app at runtime to the needs of particular users, then you don't necessarily need security on the data store so much as you need a way to keep track of who is using the database and what groups they belong to, and then what parts of the app they should have access to (and, secondarily, what level of access, read/write, read-only, etc.).
I have used Jet ULS for this last purpose for years, but have never been entirely happy with it because it's not that easy to make it user-manageable. Integration with AD would be a good choice, but that means that whoever administers your app needs to have the permission to manage AD users. This may not be something your friendly neighborhood sysadmin is willing to agree to.
On the other hand, if you end up needing both back-end security and front-end access control, you can't beat a SQL Server back end using Windows security for one-stop shopping via AD.
According to the few questions you posted these last days on Access, it seems obvious to me that you should consider switching your tables (not your forms) from an Access/mdb file to a SQLExpress server, where all these security issues can be easily managed. Upsize your database, add your connection string as a public variable in your client app (or in an xml file, local table, or anything else that can hold the string, even an extra property of your access file can do the trick through the currentDb.createProperty method), and go for a real client-server configuration.
What is the simplest way to allow one user write access and everyone else read-only access to a MS Access database on a local network?
I trust my users, but unfortunately Access saves changes to data as soon as the row of a table is deselected. Accidental keystrokes are saved without the user asking for the changes to be saved.
Some thoughts on controlling user rights to a Jet data store:
if you really want to lock things down, you'll never manage it with Jet, as it's inherently vulnerable because the user has to have WRITE access to the MDB file.
if you are content with controlling rights to the data in your front-end application, you could provide different front ends (one for WRITE users and one for READ-ONLY).
if you're not using ACCDB format, you can use Jet user-level security. It's a surprisingly complicated technology if you really want to lock down access to the data -- you have to follow all the instructions in the Jet Security White Paper to the letter, or your data will be open to anyone with the standard Jet workgroup file. And even once you're done, it is crackable (though not without spending $$$ to buy cracking software). BTW, database passwords before Access 2007 were completely useless and easily cracked. Access 2007 enhances the security by raising the level of data encryption, but a database password causes lots of issues and doesn't allow you to have more than one level of access (unless you provide two different front ends with different passwords -- cf. #2).
if you just want to use Jet ULS to control access in your front end, you can add your users to groups and then check the group membership in your front-end UI objects (i.e., forms), and give WRITE permission to the users who are in the user group that provides that level of access. The easiest way to do this, assuming you have more READ-ONLY users than those with WRITE permission is to have the READ-ONLY users log on as the default admin user (i.e., you do nothing for their setup), and have the WRITE users log on as a user in the group with WRITE permission. In other words, if they aren't logged on as user "admin", they have full WRITE access.
another alternative is to use NTFS security groups. API code for that is found on the Access Web, but it does require a Windows administrator to implement for you. Again, you would be limiting access in your front end application, rather than actually restricting user rights in the back-end MDB.
Only Jet ULS actually allows you to prevent a READ-ONLY user (who hasn't cracked your workgroup file) from editing your data. All users have to have network access to your back-end MDB, but you can make it hard for them to get to the data even without jumping through the hoops in implementing Jet ULS. Here are some steps to do that (and yes, all of these are a form of "security by obscurity" and will only slow down a READ-ONLY user determined to hack your back end):
Right click each table in your back end and turn on the HIDDEN attribute. This can also be done in code (see SetHiddenAttribute in Help). Naturally, if the end user sets their Access options to display hidden tables, this won't do anything. But most end users don't know about that, and if your users are running your app in the runtime, they won't have the option.
Change the back-end database's Startup Properties to not display the database window and to not use special keys. You can find code for setting the startup properties in the Help topic for "AllowBypassKey".
In your back-end, create a macro named AutoExec with one command, Quit. With special keys disabled, there is no way to prevent the execution of this macro, and as soon as the user attempts to open the back end (even if they hold down the SHIFT key, i.e., the standard keystroke for bypassing all startup routines), the database (and the instance of Access) will close.
Now, all of these things can be undone by someone who knows what they are doing. If you gave me a back end with these things implemented, I'd be in it in about 5 minutes, simply by running code in another Access database to change all these startup properties to give me access.
But your end users likely don't have that level of expertise. Any such user who does probably ought to be a WRITE user, no? :)
Yes, of course -- all of these things are easily hackable by anyone who knows how. But it's also easy to break into your house in seconds for the person with the right tools. That doesn't mean you don't lock the doors, even though it's not bulletproof protection from burglary.
Another consideration is that if you provide your users only the Access runtime instead of full Access, they won't be able to undo any of these settings in your back-end MDB.
Last of all:
Security is not solely a technical issue -- most of it is, in fact, a people problem. In order for people to do their work, you have to trust them to a certain extent in giving them access to your data. There is no technical solution to the problem of the untrustworthy system administrator, for instance, and the only way to fully protect your data is to not give them any access to it at all.
The easiest way would be to use share permissions. Grant write access to a group and put the users who must write to the database in that group. Put everyone else in a read group. This assumes you have a Windows domain, of course.
Here is a site that has some information on securing Access databases. It deals with Access 2000, there may be more options for newer versions.
This is the cheeky answer, but if you need better security, seriously consider upgrading to a more robust RDBMS.
I think it is possible using an ODBC connection to use Access as an interface to almost any database. For example, I have successfully configured a SQL Server 2008 Express Edition database with 2 users, one read/write and one read-only. I have been able to connect to the database from Access by opening an ODBC data source. So a user can have the Office-based report-generating and mail-merging functionality they are familiar with. But with any database server you wish.
This conversation may be a little old, but for some reasons I got the same problem recently. It will not suit to everyone, cause it relies not on M$ SQL Server but on MySQL. Use the MySQL ODBC connector (available here: http://dev.mysql.com/downloads/connector/odbc/), and store your tables on a MySQL server. The Access user's rights on tables will inherit from the MySQL user's rights. Pretty easy to customize...
Fact is, there is NO functional security for an access database.
The link below sells software that will 'recover' your access database Even if it has a a password.
It is a good thing they exist. Their program saved one of my customer's butts once when their previous programmer died and no one else had the password. Thanks to this program we could not get in and no data was lost.
http://www.stellarinfo.com/access-recovery.htm
And before you even think it, No, I do not work for them.
Can user level security enable someone to access a form, but not access a table? I have a form that is connected to a table using a"SELECT" command. It does not "UPDATE" or "DELETE". I'd like for the user to access my form, but I don't want them to be able to view the details in the underlying table. I've tried all sorts of combinations in the user level security wizard, but for some reason, my form comes up blank, unless I give complete access to the user to do anything. Any ideas? By the way, I'm on Access 2003.
You could make an MDE and give it to your users. If you do this, the users won't be able to see anything but the user interface you have provided.
If your tables are in the same Access database as the forms and queries, you first need to "split the database" into a frontend and backend. See:
http://databases.about.com/od/tutorials/ss/splitaccessdb.htm
for information on how to do this. The frontend contains everything but the tables. The backend contains the tables. The frontend is linked to the backend tables using "linked table" objects in the frontend.
Once the database is split, open the frontend in Access, and create an MDE by selecting Tools/Database Utilities/Make MDE File from the menu bar. The MDE is what you provide to the users. They open it the same way they would any other database, except that they can't design any of the objects.
Make sure that you have an AUTOEXEC macro defined in the frontend, so that when the MDE is opened by the user, it has an entry point. The user cannot see any of the objects in the MDE, so if you don't have an AUTOEXEC macro to open the first form, nothing will happen when they try to open the MDE.
If you need the ability to manage the linked tables in the MDE by allowing the user to connect to the backend database with a File/Open dialog, see the following article:
http://www.mvps.org/access/tables/tbl0009.htm
OF course, none of this precludes your users from opening the backend database. If you need stronger security, you can upsize the backend database to SQL Server Express. More info here:
http://office.microsoft.com/en-us/access/HA102755371033.aspx
What you're looking for is a RWOP query. That means "run with owner permission."
To make it work, assuming you've already run the security wizard on your front-end and back-end databases and have removed permissions for the users to even read the tables, you then create a saved query as the recordsource of your form. In the properties of the query, it is set by default to RUN PERMISSIONS as "user's." Change that to "owner's" and save the query. The query will run with whatever permissions on the base table the owner of the query has. If you are running as an administrator with full permissions, you'll want to set the permissions of the saved query to read-only (or create the query under a user logon that has read-only access to the tables -- it's much easier to do the former).
Some caveats:
user-level security is tricky. If you miss even one step outlined in the ULS security white paper, your app won't be secured. The way to test this is to open Access with a default workgroup file and then see if you can access the objects in your database logged on as the default admin user. If you can, then you made a mistake somewhere along the line.
user-level security is crackable by anyone who wants to. This doesn't mean it's not useful, it just means that it's not bullet-proof. I don't worry about that so much, as I consider security as much a people problem as a technical problem -- you have to give employees sufficient privileges to do their work, and you have trust them that they won't abuse the privileges you've given them.
if you're running Access 2007 and using the ACCDB format, RWOP queries are not available to you, as Jet user-level security is not supported for the ACCDB format. If you're using MDB format, though, it will work just fine in A2007.