Annmv888
asked on
Error when opening Access database after one user upgraded to 2016 and two still on 2010
I have three users (including myself) who have been working in a database for months with no problems. Recently one of the users was upgraded to Windows 10/Office 365 2016 and the following message occurs.
“The Microsoft Access database engine cannot open or write to the file R:\Data\...\database_be.ac
Only one person was trying to open the database and we have had the same rights since the beginning. I did notice that there isn’t an .laccdb file being created for the back-end database_be.accdb but the front-end database_fe.accdb has one.
The references for the object library were checked and fixed. The 2016 user still gets the error but the 2010 users don’t. The 2010 users do get VB code errors for Excel but at this point I don’t know if they are due to the first problem.
Any help would be appreciated.
“The Microsoft Access database engine cannot open or write to the file R:\Data\...\database_be.ac
Only one person was trying to open the database and we have had the same rights since the beginning. I did notice that there isn’t an .laccdb file being created for the back-end database_be.accdb but the front-end database_fe.accdb has one.
The references for the object library were checked and fixed. The 2016 user still gets the error but the 2010 users don’t. The 2010 users do get VB code errors for Excel but at this point I don’t know if they are due to the first problem.
Any help would be appreciated.
is the backend in the same path? , if so, are the create, and delete permissions set properly , if access cannot create the lock file it will throw that error, also (maybe the updated version does not have proper privileges) , if it is a security enhanced DB, also make sure you have correct rights to read and write to the path the .mdw is stored.
ASKER
Yes, the backend is in the same path. Support tells me all persmissions/rights are correct but I will forward this to them so they can recheck and post back after I hear from them.
Is your database split, and does each user have their own LOCAL copy of the frontend application? You must have that sort of setup with mixed versions, otherwise you'll have troubles like you describe.
You must have Read, Write, Create and Destroy permissions on the Folder hosting your backend.
You must have Read, Write, Create and Destroy permissions on the Folder hosting your backend.
ASKER
The database is split but it's on a shared network.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
Well if you want to resolve this issue...simply copy the FE to each workstation...make sure the BE tables are linked correctly e.g \\YourServer\AccessShare\d
Anything else means troubles sooner or later...
Anything else means troubles sooner or later...
Users should never share a copy of any Access FrontEnd.
The correct way to do this is as suggested earlier - give each user a copy of the FE installed on their own local workstation. Do NOT share it from a server location.
You can create a simple batch file that copies down a copy of the FE as needed and launches it:
FileCopy "source", "destination"
Start "Destination"
The correct way to do this is as suggested earlier - give each user a copy of the FE installed on their own local workstation. Do NOT share it from a server location.
You can create a simple batch file that copies down a copy of the FE as needed and launches it:
FileCopy "source", "destination"
Start "Destination"
To add some reasons to John's statement, putting a copy of the front-end file on the workstation ensures that several possible problems are avoided:
1. Performance issue when dragging front-end file bits over a network: It's bad enough just dragging the data over the network to your workstation to cause performance issues, but having to drag the FE over it too can REALLY slowdown your day. However, if you're operating your FE thru Citrix, it's o.k. to have the FE and BE on the remote machine.
2. Avoiding FE design issues: Not every part of your FE application may be sharable. It IS possible to design a part that causes EVERYONE using the FE to get the last change that anyone makes to that part while the FE is in use. For example, the recordsource and rowsource property can be changed dynamically (by code) on YOUR FE file WITHOUT affecting anyone else (its a sharable part), but if ANYONE changes the SQL property of a querydef object, then EVERYONE using that querydef object instantly gets that SQL - and they see their data change before their very eyes! The Querydef.SQL property is NOT a sharable property in a shared FE file!
Be safe, but within reason....
1. Performance issue when dragging front-end file bits over a network: It's bad enough just dragging the data over the network to your workstation to cause performance issues, but having to drag the FE over it too can REALLY slowdown your day. However, if you're operating your FE thru Citrix, it's o.k. to have the FE and BE on the remote machine.
2. Avoiding FE design issues: Not every part of your FE application may be sharable. It IS possible to design a part that causes EVERYONE using the FE to get the last change that anyone makes to that part while the FE is in use. For example, the recordsource and rowsource property can be changed dynamically (by code) on YOUR FE file WITHOUT affecting anyone else (its a sharable part), but if ANYONE changes the SQL property of a querydef object, then EVERYONE using that querydef object instantly gets that SQL - and they see their data change before their very eyes! The Querydef.SQL property is NOT a sharable property in a shared FE file!
Be safe, but within reason....
ASKER
Thanks everyone for all the help.