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.
Related
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
I'm trying to change the schema of an Access 2013 table. I want to lengthen some of the text fields. When I change the schema and try to save I get dialog with Operation is not supported for this type of object, and a note that This property cannot be modified in linked tables. That makes sense. So I go to the relationships and try to delete one of the links. This gives me the error: You can't delete a relationship inherited from a linked database.
I don't know of any "linked databases" (I didn't create the database). Is there a way I can figure out what/where these might be?
Examine the TableDef properties for your linked table.
Here is an Immediate window session which examines properties for a linked table named remote_Foo:
' Connect identifies the database source of the linked table
? CurrentDb.TableDefs("remote_Foo").Connect
;DATABASE=C:\share\Access\BigDb_secure.mdb
' SourceTableName is the remote table name
? CurrentDb.TableDefs("remote_Foo").SourceTableName
tblFoo
You can use Ctrl+g to go to the Immediate window.
In Access 2010, that information is also available from the Linked Table Manager, which can be opened by right-clicking a link name in the Navigation pane and then choosing it from the shortcut menu. I don't know whether that option has changed in Access 2013.
You will need to make your design changes on the table in the remote database. Then recreate the link or use its RefreshLink method so that Access will recognize the design change and update the metadata it maintains for that link.
Your Table must be linked to Sharepoint site.
Go to "External Data" field and click "Work Offline" button (its a toggle button).
Make any schema changes.
Click again work online tab to sync changes to sharepoint.
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 am working with Access 2003 and I need to change the filepath for a Query. I am working on a database that I did not create and basically my workflow is using Excel to populate a list (file names and info about photos)
Then I go back to Access and in Query's I have an option for "Append Results" which will update my database with my new information that has been loaded into Excel.
I get an error saying that the filepath is wrong. I know the correct filepath and this is a correct error, I just can't find where to update the query so I can change the filepath. I did a couple of googles and used microsoft help but figured it might be faster to ask in here.
Thank you,
JWV
It sounds like the workbook is linked to Access as a linked table. Sort your objects by type, and try and open each linked table until one fails. Then drop the link, and re-create it to the correct spreadsheet with the same table name.
To do this, you first backup the *.mdb (in case you get it wrong) and then just delete the link, like you would delete a table. Next you need to right Click on any table => Import Spreadsheet => Go to your spreadsheet and untick the box that says 'Import into database' (or something similar, I don't have access to Access (ha!) at the minute to test), this will give you a link to the spreadsheet, as opposed to actually copying it as a table, then rename it so it is the same name as the original link.
I guess as an alternative you could remap the drives so that, on machines where this needs to run, the old I: drive is mapped back to I:, and the same for H:.
i have an access backend MDB
it is supporting multiple user connections
every user has their own access front end
for this one particular user (her permissions arent any different from other users) she is getting FILE ALREADY IN USE error when she tries to open this database using her front end
if you have any suggestions please let me know asap, as this is urgent for me
But are this users permissions for the BE Access database file folder different than the others? Can that user create, update and delete a txt file using Notepad in the same folder as the BE?
In her front-end, go into Tools->Options->Advanced. Change the default Open mode from Exclusive to Shared.