We have an Access Database-Solution with Frontend and Backend Database running for years.
Now within the last two days problems occurred. E.g.
Set db = DBEngine.OpenDatabase(strDatabasePath, False, True, "MS Access;PWD=" & strPassword)
Does result in Error 3050 - File could not be locked. ONLY when the Backend Database is on a network share (if it's on a local drive everything works as expected).
The error occurs on any share:
a Shared Folder from a Windows PC
a Shared (Samba) Folder on a NAS
independently whether the share is accessed via a UNC-Path (\server\share) or a mapped drive-path.
The error was introduced by a faulty Office Patch (seems it was V2111 - 14701.20240)
In the first version of this post I thought that Windows-Update KB5008212 was causing the problem.
Thanks to #Gustav for identifying the problem.
How do we find out WHEN MS pleases to fix the problem?
From Microsoft:
This is due to today’s (Patch Tuesday) update to Office. The problem
was introduced by a security fix, so it impacts all active versions of
Access. We are working on a fix, and will deliver it as quickly as
possible.
The update has only been set to automatically update a very small
percentage of users, and it looks like we will be able to pause
automatic updates, so it will not propagate.
There will be a page added to the
Fixes or workarounds for recent issues in Access (microsoft.com),
which will then be the place to go
for updates.
These are the updates that introduced the problem:
KB 5002104 for Office 2013
KB 5002099 for Office 2016
Office 2019 Version 1808, build 10381.20020
Office LTSC 2021 Version 2108, build 14332.20204
Microsoft 365 Apps:
Current Channel Version 2111, build 14701.20248
Monthly Enterprise Channel Version 2110, build 14527.20340
Monthly Enterprise Channel Version 2109, build 14430.20380
Semi-Annual Enterprise Channel (Preview) Version 2108, build 14326.20692
Semi-Annual Enterprise Channel Version 2102, build 13801.21086
Semi-Annual Enterprise Channel Version 2008, build 13127.21842
If you did get updated to one of those builds, the only solution
currently is to move back to an earlier build in the channel.
Installing version 2008, in fact, resolved the issue for me. Microsoft just released new builds of versions 2108 and 2112 yesterday, 01/11/2022, that also resolved this same issue for me.
We had the same problems.
Uninstalling Office 365 (32-bits) and re-installing Office 365 (32-bits) from the OfficeWeb-Portal seems to solve the problem.
Ours is not manifesting in the same way. I seem to get a lot of orphaned lock files. Users are having some problems getting in to the databases but usually If I delete the lock file and have them wait 5 minutes, the problem goes away. Since this started it has been a game of running daily backups to a separate file just in case. Major Pain in the you know what. I'll keep an eye on what crops up here. Thanks folks (Yes this is more of a comment than an Answer, but I needed more characters)
Related
We have an Access Database-Solution with Frontend and Backend Database running for years.
Now within the last two days problems occurred. E.g.
Set db = DBEngine.OpenDatabase(strDatabasePath, False, True, "MS Access;PWD=" & strPassword)
Does result in Error 3050 - File could not be locked. ONLY when the Backend Database is on a network share (if it's on a local drive everything works as expected).
The error occurs on any share:
a Shared Folder from a Windows PC
a Shared (Samba) Folder on a NAS
independently whether the share is accessed via a UNC-Path (\server\share) or a mapped drive-path.
The error was introduced by a faulty Office Patch (seems it was V2111 - 14701.20240)
In the first version of this post I thought that Windows-Update KB5008212 was causing the problem.
Thanks to #Gustav for identifying the problem.
How do we find out WHEN MS pleases to fix the problem?
From Microsoft:
This is due to today’s (Patch Tuesday) update to Office. The problem
was introduced by a security fix, so it impacts all active versions of
Access. We are working on a fix, and will deliver it as quickly as
possible.
The update has only been set to automatically update a very small
percentage of users, and it looks like we will be able to pause
automatic updates, so it will not propagate.
There will be a page added to the
Fixes or workarounds for recent issues in Access (microsoft.com),
which will then be the place to go
for updates.
These are the updates that introduced the problem:
KB 5002104 for Office 2013
KB 5002099 for Office 2016
Office 2019 Version 1808, build 10381.20020
Office LTSC 2021 Version 2108, build 14332.20204
Microsoft 365 Apps:
Current Channel Version 2111, build 14701.20248
Monthly Enterprise Channel Version 2110, build 14527.20340
Monthly Enterprise Channel Version 2109, build 14430.20380
Semi-Annual Enterprise Channel (Preview) Version 2108, build 14326.20692
Semi-Annual Enterprise Channel Version 2102, build 13801.21086
Semi-Annual Enterprise Channel Version 2008, build 13127.21842
If you did get updated to one of those builds, the only solution
currently is to move back to an earlier build in the channel.
Installing version 2008, in fact, resolved the issue for me. Microsoft just released new builds of versions 2108 and 2112 yesterday, 01/11/2022, that also resolved this same issue for me.
We had the same problems.
Uninstalling Office 365 (32-bits) and re-installing Office 365 (32-bits) from the OfficeWeb-Portal seems to solve the problem.
Ours is not manifesting in the same way. I seem to get a lot of orphaned lock files. Users are having some problems getting in to the databases but usually If I delete the lock file and have them wait 5 minutes, the problem goes away. Since this started it has been a game of running daily backups to a separate file just in case. Major Pain in the you know what. I'll keep an eye on what crops up here. Thanks folks (Yes this is more of a comment than an Answer, but I needed more characters)
Background:
I've been supporting a legacy MS Access Front end with Linked Tables to SQL Server for about a year. The code is terrible, and we're re-writing as an MVC App. But for the next year or so we still have to support it.
Last week I upgraded my laptop. More RAM, bigger HHD etc ... On my old laptop, I had a copy of the SQL Express Database, and the Access, and it ran fine. I open a form in Access, and it appeared after a couple of seconds.
New laptop. Twice the RAM ... takes minutes to load the same form with the same database running locally. When I look at the SQL Server, I see the queries that the Access is calling and they're all with ASYNC_NETWORK_IO
My task manager on my PC shows memory running at 40%, and CPU at 30%. There is no network as Access and SQL are on the same PC.
Does anyone know why the Access front end would be taking minutes on my new laptop, compared to seconds on the old, to load the same form?
Thanks in advance.
Answering my own question for the next unfortunate person who has the issue.
On my old laptop I was running SQL Express 2019
On my new laptop I installed SQL Developer Edition 2019
Clutching at straws, I installed Express 2019 on the new laptop, changed the connection string, and it's back to working normally!
Unbelievable that using Developer Edition caused so much more heartache than Express ... would love if someone could answer that for me!
I have a Desktop: MS Office Pro Plus 2016 & Win10 Pro 64bit v1909, and also a Laptop: identical setup but different Office keys all fully activated. MS-Access has started throwing an error (exactly same on both machines) since the latest Windows update. This error is happening with a standard "Desktop Database" stand alone / not shared etc.
Whenever I try to Compact & Repair or File / Save As, MS-Access errors with-
"Could not use 'path\file.accdb'; file already in use".
This did not occur (on either machine) before the latest Windows updates. It occurs for both new DBs and existing DBs. I have tried: Permissions in the folder: I'm using an Admin Account and can read/write/update/delete etc-so no issues. I've also disabled all Firewalls, Anti Malware to see if that was the problem - same error. As the same thing has occured on 2 independent machines after the same Windows update, it makes me suspicious of that - has anyone experienced the same error or have any idea how to solve this?
Many thanks for your help in advance.
Kind regards,
Bob
I have a handful of MS Access 2010 databases that are used to keep track of various things for my group. Each Database has a dedicated back end and each user has a local copy of the front end (*.accdr) and 2010 access runtime. Only three of us have full versions of Access. Each DB has up to 6 users and some users have multiple DB's they use regularly. One user in particular has multiple problems with these DB's. One of them has a form where you put criteria in some text boxes, click a button and another form opens displaying data. Everyone else has this perform seamlessly. On hers, it throws up a dialog box asking for the criteria a second time. This is pretty universal across the DB's that she uses. On another DB, Clicking a button triggers a macro to export of a query to a MS Excel spreadsheet. This will generate an unspecified runtime error and then shutdown the entire frontend. Again, this works fine for other users.
I have systematically gone through and tried each DB from each user's computer. I have checked and rechecked the source *.accdb files I generate the front ends from. The problem seems to exist only on this user's computer.
She does have a full copy of Access 2010, but she doesn't ever use it. She also has 2010 runtime. All of our machines are connected by Ethernet to the server where the Back ends are stored.
I would expect the front end to behave the same way on her machine without unexpected pop ups or runtime errors since it behaves as it should on every other user's machine. I don't know what to look for now, and I am not inclined to throw up my hands and blame a bad setup on her machine. Is there some logical steps I can take now, since IT support is one place no sane person in my office wants to do (bad for the blood pressure). Any help, advice, or even Mystical Incantations would be appreciated.
This is a common occurrence.
The HUGE MASSIVE tip-off is that the accDB works, but the accDE (pre-compiled) does not.
And the next HUGE MASSIVE tip-off is compiling the accDB to an accDE on that particular machine ALSO works.
The reason and problem for this is that the version of Access running on that machine does not match the save version that you are running on other machines. (Specific the machine used to compile the accDB into the accDE).
While of course you are running access 2010 on all machines, the problem is the SP update version (Service Pack(s) installed).
Keep in mind that the runtime is NOT updated by windows update.
Keep in mind that running the office SP update will NOT update the runtime (but this will only apply to runtime only machines).
So, on your dev computer? Well automatic updates can roll out a SP update to office 2010.
However, automatic windows updates NEVER update the access 2010 runtime. You must install the 2010 runtime SP updates manually. So with a mix of runtime and full editions?
Well, the machines with full edition will wind up with SP updates occurring (they over write the runtime on those machines). In fact, you can’t install both full and runtime on the same machine. The installer allows this, but it is a “fake” install, and installing the 2010 runtime on machines with full edition in fact does NOTHING!! (Well, it does create a “fake” entry in the list of programs installed – but it DOES NOT actually install the runtime, since it would overwrite the full edition that already exists on the machine).
On computers with the full edition, then installing the SP updates to office, or even allowing windows update to do this will NOW cause the 2010 version to be DIFFERENT then your developer machine.
The reason why the accDB works is because Access (even the runtime) will detect that the “sp version” is different, and re-compile the VBA on the fly. Even the stand alone runtime version is able to re-compile the source VBA code.
However, with an accDE?
The code is pre-compiled, and thus no on-the fly re-compile can occur. There is no source code. The accDE should and often MUST be run + consumed by the SAME sp update version.
To reduce, or all but eliminate this issue?
Well, on your dev machine, make sure the sp2, or sp3 update to office has been applied.
On the target computers? If they are runtime only, then you MUST install the sp2 or sp3 update to the access runtime. I cannot stress that you MUST download and install the SP2 or SP3 update for the access runtime. The office sp update WILL NOT work nor will it update the runtime version on runtime only machines.
Because of the above?
I recommend you download the 2010 runtime. Download the sp3 2010 runtime update, and “slip stream” the sp3 update INTO the 2010 runtime installer.
You can then provide the customer site (or your site) with a folder on the server with the runtime to install, and WHEN you install the runtime, then the sp3 update will be included in that install.
If you (or your IT department) does NOT know how to slipstream in the sp3 update, then simply ALWAYS have then install the 2010 runtime, and then ALWAYS install the sp3 update for the 2010 runtime.
Doing the above will eliminate the issue of the AccDE having been created and compiled with a different release version of access.
Last but not least?
No question you want to continue using a compiled accDE, since with the runtime, then any un-handled error with an accDB will not only spit out an error message, but shutdown the whole application.
So:
With accDE:
Errors NEVER re-set global or local variables.\
Errors will NEVER cause a shutdown of the runtime.
Even un-handled errors will NOT cause a shutdown of your application.
Un-handled errors will NEVER re-set local, or global variables they will ALWAYS no matter what retain their values for the duration of the appcation session.
With accDB and runtime:
Any un-handled error will blow out all local and global variables.
Any un-handled error will then shut down the runtime after display such errors.
Bottom line:
Using an accDE is thus vastly far more reliability then an accDB when using the runtime.
OK, First of all, thanks for all your suggestions in the comments. We figured a method to keep my user working, so I will put it here.
We reasoned that since the executable ran fine on multiple machines, there may have been some sort of unknow quirk in my users machine that was causing the issues. I started my re-making the front end in the normal way and pushing it out to just the one user. It failed just like before.
Since she had a full copy of Access 2010, we opened the source *.accdb file directly on her machine. That time, It worked just fine.
From there I went, possibly a little overboard. But it worked out.
I opened all the forms in design view. Double check for errors, then save each form in turn. After that, I did the same with the macros. Not making changes, but checking the work.
Next I ran a compact and repair, from the affected machine.
Then I used the affected machine to create a new front end executable.
Lo and Behold, it worked. The affected user now has a completely functional front end.
This is going to make updating the front end a pain in the keister moving forward, but at least now I know what will actually work.
Thank you for your help
My question about the reconfiguration delay when switching between Access 2003 and 2007 the comment was made:
Btw, you can't avoid the reconfiguration between Access 2007 and earlier versions. Access 2007 uses some of the same registry keys as earlier versions and they have to be rewritten when opening Access 2007.
If this is so then is it actually safe to be running/developing databases in both versions at the same time? Do the registry changes affect the operation of Access once it has started up. For example recompiling/saving changes to objects?
It works most of the time but it's not perfectly safe, which is why Microsft refuses to support multiple installations of Microsoft Office on the same pc. The recommended solution is to install a virtual machine and install the second Microsoft Office version on the virtual machine. Then you can switch from one version of Access to the other without them interfering with one another (and no switching time wait!)
Microsoft offers a free download of Virtual PC 2007 in both 32 bit and 64 bit versions:
http://www.microsoft.com/downloads/details.aspx?FamilyID=04d26402-3199-48a3-afa2-2dc0b40a73b6&DisplayLang=en
Here's the service pack:
http://www.microsoft.com/downloads/details.aspx?FamilyID=28c97d22-6eb8-4a09-a7f7-f6c7a1f000b5&DisplayLang=en
It is perfectly safe, I have done it very often (both running and developing). As soon as you open a database in Access 2007, some extra properties will be added to the database. However, this is done in such a way that you can still open the database safely in Access 2003 at a later time.
We also have databases installed in a multi-version environment were different people use the same backend, with the front end opened in Access 2003 or 2007.
It seems to me that the instance of Access you open will inherit the registry settings at the time it is open. So, if you open A2K7, you'll get the registry settings that it writes in its "configuring Office" procedures. If while A2K7 is still open, you open A2K3, it will reconfigure the registry settings and inherit those for its session. This will have no effect on the already-running instance of A2K7.
The only possible exception would be if there are some registry keys that the "configuring..." process changes that Access doesn't read upon opening, but later in the session. I have strong doubts that MS would ever design things that way. Professional Access developers been dealing with this kind of thing since MS introduced the MS Installer (first seen by most people with Office 2000), and the A2K7 issues are only slightly worse than with previous versions (though on Vista, it's more complex because of the way Vista handles registry changes). The fact that MS gets the vapors over contemplating multiple versions of Access on a single PC does not mean that it's actually dangerous -- it shows only that they don't want to devote resources to supporting that scenario.