Access Broken today 10th May 2022

I have further information which may help to understand the problem.

My application has a client form and a bookings form. The client form has a subform with a list of that client's booking. The user can "drill down" from the client form to see the details of a booking on the booking form. When they do that, the application closes the client form and then opens the bookings form.

The following error message is displayed as soon as the bookings form is displayed:

The object doesn't contain the Automation object 'Blacklisted.'

The client form also has a function to create a new booking for the client. In this case, the application closes the client form and opens the booking form in data entry mode to create a new record.

When they do that, Access emits a beep (as if it is displaying an error message) but no message dialog is displayed. It then crashes.

Now what is of interest is that I have no objects/properties in the database called "Blacklisted". None. There are no fields, forms, controls or anything else called Blacklisted. However I do have a field on the client form called Blacklist and a client is considered to be "blacklisted" if that field is set.

So I used Brent Spaulding's excellent SearchForText utility ( https://www.utteraccess.com/topics/1992076 ) to search my database for "Blacklisted" and found a conditional format expression [Blacklisted] on the client name field of the client form. It is supposed to show blacklisted clients in red text.

NOTE: This is the form which is closing. The object name does not exist anywhere else in the database.

What this means is that once upon a time the Blacklist field was called Blacklisted and when it was renamed, the conditional format expression was not updated. As a result the conditional formatting is causing an error because it has a bad expression. However errors in conditional formatting expressions do not always surface, they just fail to cause the conditional formatting to be applied.

I removed the conditional formatting expression, and hence the source of the error.

Now when I drill down to the booking form, the following error is displayed:

No Current Record

(sound familiar?)

When I create a new booking record, the following error is displayed:

The Microsoft Access database engine does not recognize 'ContextListFill' as a valid field name or expression.

The system no longer crashes.

Now "ContextListFill" is a combo box filler function used as the ControlSource of a combo on both the closing client form and the opening booking form. Instead of crashing, Access appears to be displaying some other miscellaneous message about the closing form.

What is significant here is that this shows:

1. The error message is being displayed by Access as it closes a form. it is clearly trying to requery/refresh the dying form as it closes.
2. If Access cannot handle an error which occurs as the form closes, it crashes.

The crash appears to be Access's equivalent of us getting a Continue/Debug/End dialog in VBA if we don't handle a runtime error properly.

Although this is not a solution, it is a workaround which has allowed me to downgrade the severity of the error from a system crash to an irritating error message. I hope this information helps others to workaround the problem while Microsoft work on a fix.

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.

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

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

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.