So after some digging I realize that there is no built in user level security option for Access 2007. What I need to do is restrict records that users can edit based on who is logged in (they can see all the data but only edit their own). I was thinking that I could make a log in form and assign passwords and go from there, but I was wondering if there was a better method to do this.
For user privileges for read-only, read-write on forms in the database, we implemented following tables, logic.
I created a privilege table along with log-in table. Each screen in the database will have Read-only or Read-write privilege to each user. I inserted all the screen names into privilege table. Another table UserPrivilege will have users and their privileges. Assigning privilege to an user will be done only by Admin user.
A function at start of each form check swhether a specified user is allowed to view or edit form. If he/she is given read-only, we will lock all controls looping thr' controls on the form. Else, nothing to do. OR keep all the controls read-only at design them and unlock them thr' code for write privilege.
The database window is kept hidden when a version to end user is delivered. This prevents usual , simple view to tables in the database, opening forms , reports object in database window. After making mde/accde few more tweaks can be done so that user is not easily able to view tables directly. by-passing startup, special keys etc.
I have been facing this problem too. My solution (which hasn't been broken yet) is to do exactly that. Make a user's table with passwords and a log in form which reads the table for User name, password and user type. I have used two ways to proceed from there: Case statement to open specific navigation forms for that user's functions or a global variable (in a module (enumeration helps)) and an getter function that is checked within each form's open events and changes properties like AllowEdits, and AllowAdditions and even cancel the form opening if it's administrative stuff.
The most important part of this set up is making sure the users are using Access Runtime. If they use the Access version you are developing in they can snoop a little bit and get around this.
Make sure you hide the user's table.
Access runtime can be forced by making a shortcut to the DB and adding /runtime to the end of the shortcut path (with a space).
It's not perfect, but it works for my purposes and It might work for your's.
I did dot this in 2010, but 2007 should be pretty much the same.
Assigning username/passwords in Access (especially with an access back end) has a number of critical issues that are worth pointing out. Firstly, if you don't encrypt your DB, then any of your users who are savvy enough to go looking for it will be able to find it, and therefore get full access to it. If you encrypt the DB, if anyone can get access to your source code you're toast, since they will be able to see the DB user/passwords stored in the code. This issue persists if you use other SQL db's, but at least in those cases you can restrict the user supplied to the Access .accdb file to have certain permissions.
For my case, I have 3 levels of security. Firstly, I heavily restrict what I send out to make it very difficult to access the source code, which you kind of have to do no matter what. Secondly, I distribute different levels of access with different DB passwords (I'm using a MySQL back-end, you could do the same with a SQLServer back-end, but with Jet you're out of luck), so even if users could see the DB user and password, they are limited in what they can do. Thirdly, since I deploy on a corporate network, I take advantage of windows groups, and use those to filter out what is visible to different users. That way, users can only use the forms if they are authenticated onto our network. If the file discovers it's not on the network, it deletes itself and terminates.
Function IsMember(strDomain As String, strGroup _
As String, strMember As String) As Boolean
Dim grp As Object
Dim strpath As String
strpath = "WinNT://" & strDomain & "/"
Set grp = GetObject(strpath & strGroup & ",group")
IsMember = grp.IsMember(strpath & strMember)
End Function
Function GetCurrentUser() As String
GetCurrentUser = VBA.Environ$("USERNAME")
End Function
Function GetCurrentDomain() As String
GetCurrentDomain = VBA.Environ$("USERDOMAIN")
End Function
Related
I am currently using an access DB with front and back end. When I want to allow new users to access the DB I add the user to the folder in which the DB is housed. Essentially if they determined the path of the DB they could copy it ect.
Is there anyway to still allow access to the DB through the Access front end yet still prevent the user from actually getting to the directory of the file.
Thanks in advance for all your help.
No there isn't access is a file based dbms. For the app the user is running as to see the file, the user has to be able to.
This is the sort of need that says access cannot be used. Well not directly , you could use access as a backend, ie you park it behind some sort of service and your front end hits that.
yo keep an integral copy for you in case of changes then with the pblic copy, for example
with Access 2007 you click files -> Options -> active data base -> Navigation Options.
then you hide all the elements...
I have a 2010 Access Database that I split for so multiple users can use the database at the same time. However, now I can't add data to the front-end through tables, queries, anything. When I go to the back-end it says it's read only and I can't add data or modify design there either, and yes I have proper permissions to view everything. I even tried setting the permissions to Everyone with Full access but it still doesn't work. Any ideas?
When you open the back end db file, Access must be able to create a lock file, or update the lock file if one already exists. When neither happens, the db file will be opened read-only.
That requirement applies when you open the back end db file directly in an Access session. It also applies when you open the back end indirectly from your front end database.
The lock file uses the same base name as your db file, but a different file name extension: .ldb for an MDB db; or .laccdb for an ACCDB db.
Make sure your users have permission to create and delete files in the folder where the back end db file is located. Alternatively, you could just give them modify permission for the lock file once it has been created.
If the problem is not a lock file issue, open one of your linked tables in datasheet view from the front end and see whether you can make changes (add and delete rows, and update values in existing rows). If the linked tables are treated as read-only, delete the links and recreate them. Make sure to inform Access which field or combination of fields to use as a primary key. In the absence of that information, Access will link the tables read-only.
If the linked tables are not read-only, inspect your forms' record sources and other properties. Some queries can still be read-only even though their source tables are editable. And the Data tab of a form's property sheet includes properties such as Allow Additions, Allow Deletions, and Add Edits ... which influence the types of changes which can be made through that form.
Finally, make sure all front end users have default open mode set as shared. If any user's open mode is set as exclusive, all later users can only open read-only.
I have an access database that is saved in a network location so that any of the 600 employees who work at the company can access the database. When they open the main form it runs a make-table query. However there is a popup from MS Access stating "You are about to run a make-table query that will modify data in your table. Do you want to continue?"
The form will not run correctly if they do not press yes so I want to suppress this prompt so that it does not ask them. I changed the settings from the Options>Edit/Find>Confirm menu so that it doesn't show this confirmation. However, this is apparently a local setting so to enforce this every user would have to change those settings.
Is there any other possible solution to suppress the confirmation message?
There is so much wrong here, I hardly know where to start:
you can't possible have an Access database used by 600 people.
if more than one person opens it and runs the MakeTable, it will break, because you'd be making a structural change that collides between the two users.
turning off error notification is a HUGE MISTAKE. You don't know exactly which errors you might end up ignoring.
turning off SetWarnings means that you can get inconsistent updates from a SQL DML statement, and then you have no way to know which data was updated or not.
MakeTable queries do not belong in any production application. Instead, create a persistent table, and clean it out and append new records to it. But it doesn't belong in your main application -- this is the very definition of temporary data, since it's constantly being replaced, so it needs to be in a separate temp database.
you'd likely want all users to have their own temp databases so there are no collisions if more than one opens the app at a time.
Yes, from VBA:
DoCmd.ShowWarnings False ' Don't show warning popup
DoCmd.RunQuery "MyMakeTableQuery" ' Run the make table query silently
DoCmd.ShowWarnings True ' Turn warnings back on
Use DoCmd.SetWarnings False to stop the message box from popping up. Be warned, however, that this action is global to the Access application. You have to re-enable warnings with DoCmd.SetWarnings True as needed.
You can also try:
Application.SetOption "Confirm Action Queries", False
If you don't already, you may want to have a hidden form open every time the database is opened. You can use the OnOpen event of that form to run startup code like the above.
Our MS Access 2000 developer left the company a year ago. We need to open his app in design mode in order to make modifications. Double-clicking the .mdb file while holding the shift key doesn't work. When I do that the developer toolbar shows for a split second, then all toolbars go away and the app opens as users would see it. No toolbars show and only a basic dashboard is visible to run the app. I tried using the password recovery tool mentioned here but the tool says there is no password. Can someone tell me how I can open this app to make code modifications?
Beth's answer worked for myself and a co-worker. I've copied the solution here from the link in case the link dies.
"...To unlock the Access DB you can use the following if you know the full path to your database.
Copy the following function into a module in ANOTHER database and call the function. You will need to set the strPath to the path of your database."
Public Function ResetExternalDatabaseBypassKey _
(Optional tfAllow As Boolean = True)
'Name: ResetExternalDatabaseBypassKey (Function)
'Purpose: Sets AllowByPassKey to true in another Access Database
'Author: John Spencer UMBC-CHPDM
'Date: May 02, 2000, 12:08:19 PM
'*******************************************
Dim dbs As Database
Dim strPath As String
On Error GoTo ResetExternalDatabaseBypassKey_ERROR
strPath = "C:/MyDatabases/SomeDataBaseName.mdb"
Set dbs = DBEngine.Workspaces(0).OpenDatabase(strPath)
dbs.Properties("AllowByPassKey") = tfAllow
ResetExternalDatabaseBypassKey_ERROR:
Select Case Err.Number
Case 3270 'Property not found
MsgBox "Allow Bypass Key property does not exist " & _
"for the chosen database."
Case Else
MsgBox Err.Number & ": " & Err.Description
End Select
End Function
Make sure there wasn't another copy left around without this code enabled.
This is typical code used to do this sort of thing, SetByPass There are instructions to hit Cntl-G to open VBA Editor and run code to unset this thing.
Have you tried creating a new blank database, and then importing everything?
It sounds like the shift key by-pass has been set, but that's as noted usually only needed for deployment. In fact, for any access developer, this is quite much a standard approach.
So, it not clear if anything at all been locked up here or the person just set things up as most access applications should be when deployed to users.
About the only thing you lose when importing to another application is the tools startup settings and the shift key. If there are custom menus, make sure you check the option to import those also. (However, be careful, as sometimes custom menus can be setup to run a macro on startup, and this was an old security trick). So, if importing once with tool bars and holding down shift key still causes startup code to run, then try creating another blank database and this time import everything except the menu+tools bars from the old application. Holding down shift key will thus then work for you.
Also, if the system not asking your for a password, then what would you expect a password recovery program to do? All you need is basic access developer skills here to deal with this problem and throwing things like password removal when you not being prompted for passwords will not move you forward here.
On the other hand, if after importing all the forms into a new database the design ability is grayed out, then this was in fact a mde file, and you are in a rather difficult situation unless you can find the original mdb file used to create the mde.
According to http://support.microsoft.com/kb/288902/en-us
You can attach to a specific instance
if you know the name of an open
document in that instance. For
example, if an instance of Excel is
running with an open workbook named
Book2, the following code attaches
successfully to that instance even if
it is not the earliest instance that
was launched:
Set xlApp = GetObject("Book2").Application
Th example works for Excel, mainly because the "Document Name" is nearly the same as the filename. I need to get this to work for Access.
I have users running multiple instances of different Access Applications (.ADP) and I need to get one with a specific name. I do NOT know the complete filepath, otherwise I could do a simple
Set app = GetObject("c:\my\app\myapp.adp", "Access.Application")
Currently, I go with calling
Set app = GetObject(, "Access.Application")
and check the returned Application.Name. If it's good, I use it to call some functions on it, if not it fails. I have heard about the Running Objects Table, but since I have to get the object inside a VBScript, it's a bit too much API-calls.
Bottom Line:
What is the correct "Document Name" of an Access ADP to use in the GetObject("Document Name") call and what type of object does it return?
Coming back to this question because #phoog posted an answer, it occurs to me that since Access can have only one database open at a time, you'd need to look at each instance of Access and check its CurrentDB.Name. Now, with an ADP, I don't know what you'd check instead, but perhaps it's CurrentProject.Path.
I don't believe any of that actually addresses the original question, which seems to want to find the instance with just the filename, but I don't think that even if that worked it would be a good idea. You could easily have independent Access apps that return the same application name and filename but are stored in different locations in the file system.
You probably want to read this: http://support.microsoft.com/kb/147816
Unfortunately, it looks like "Document Name" has to be the mdb file, so if you don't know the file path, you're not going to be able to use "Document Name".
In addition to the fact that Excel can have multiple documents per instance, Excel also prevents you from opening two documents with the same name, even if they are in different folders and you are opening them in different instances of Excel.
On the other hand (to address David-W-Fenton's comment), Access does allow you to open multiple instances of the same database (not to mention different databases with the same name), as long as you don't open any instance in exclusive mode.
This is further evidence that the way Excel registers its documents in the ROT is very different from the way Access does so.