Access Broken today 10th May 2022

Same here "the search key was not found in any record" this happend on close form

This is happening to my database on all machines since yesterday (Version 2204 Build 16.0.15128.20128) 32-bit.

No Current Record

Invalid Operation

Search Key Not Found in Any Record

I was able to fix one form by removing Recordset.MoveLast and replacing it with DoCmd.GoToRecord , , acLast.

Error pops up after Closing a Form or Opening it in Design view and seems to only occur only on Single Forms containing a Subform. It does not appear to affect Continuous Forms or Single Forms without a Subform. Edit Subform presence is irrelevant.

Common theme also seems to be if .findfirst / .movelast is used on the main form, either by opening with or subsequent searching.
Opening the form with no code and closing the form otherwise does not pop the error.

Yesterday one of my clients reported an onslaught of errors as follows:

• No Current Record
• Property Deleted
• The expression you entered refers to an object that is closed or doesn't exist.

This is intermittent. It occurs as one form is closed and another opens.

If I put a breakpoint in the form’s error handler, but the error is not trapped (i.e. i does not occur in the Form_Error event). Neither is it trapped in any other of the form's other event handlers.

"The expression you entered refers to an object that is closed or doesn't exist." refers to a subform on the form which is closing, as opposed to the form which is opening.

If you hit Ctrl-Break when the error message is displayed, the system does not enter break mode.

For some users, Access then crashes.

All of this evidence suggests that the problem is occurring as a form closes, rather than as it opens.

The system is running on an RDS server, so all users have the same environment/versions/permissions.

The database has not been updated or changed for over two years, so it is not an application/coding issue.

The windows server is 2.10.0.14393 and has not been updated since 26-April-22.

The client runs 32-bit Office 365 The Office version was initially 15128.20178.

This had last been updated on 02-May-22. However the errors didn’t start occurring until 10-May-22.

I suspected the latest version of Office so I rolled back the version to 15028.20160. The problem persisted.

So I rolled the update forward again to 15128.20178. Now the users could no longer share the database. The second and subsequent users got error “Could not lock file”. This is reminiscent of the recent file locking issues that have plagued Access since December 2021. See https://www.devhut.net/access-lock-file-issues/ I thought that the file locking bug had returned. So I rolled back to 14701.20226. This did not fix the file locking issue. So now I thought that the whole Office installation was in some sort of a mess. So I uninstalled Office altogether, rebooted the server and reinstalled Office. This time I got build 15128.20224, a new build which had not even been fully released at that time (it is now listed as the current release, dated 10th May). The locking issue persisted. Then I realised that the database was opening in read-only and that there was a file permissions issue. I changed the folder permissions to Modify for all domain users and the file locking issues went away.

The reason I include all this information about the file locking issue is because I led up that path because I found that my user account (Domain Admin) did not have appear to be experiencing the new errors but the client’s (Domain User) accounts did. The problem appeared to be permission related.

What I don’t understand is why the locking error reared it’s ugly head. Perhaps I inadvertently made a permissions change and I don’t fully recall the details. The fact remains that I had to change permissions as part of my troubleshooting.

The evidence also suggests that this problem is not simply version/build related. My users had been running the same build of Office on the same build of Windows for a week before the error started to occur. But within a day some annoying random errors have escalated into crashes which are making the system unusable for some users.

I hope that my information will help with the debugging process.

Kind regards

Neil Sargent

Thank you very much for your detailed post.

I am currently rolling back Office 365 on one of my PCs in the hope that it will fix the issues, I don't hold out much hope though.

UPDATE: The rollback has just been completed and my database is working again. I rolled back to

I've done further research and it seems to be a problem with the new Accesss version and using Recordset. commands.

Forms without using Me.Recordset.FindFirst / .Movelast in the VBA code etc, do not pop this error on close, but any forms that do will pop the error on close.