MS Access – reliability of ADXAccessAppEvents.OpenDatabase and safe timing for write access

Add-in Express™ Support Service
That's what is more important than anything else

MS Access – reliability of ADXAccessAppEvents.OpenDatabase and safe timing for write access
 
Subscribe
Norman Neubert




Posts: 17
Joined: 2022-06-09
Hello,

we maintain a COM add-in built with Add-in Express for Office and .NET (currently 10.2.4714), registered for both Excel and Access (SupportedApps = ohaExcel Or ohaAccess). In Access we only subscribe to ADXAccessAppEvents.OpenDatabase. In that handler we do real work on the database that was just opened: we read and write custom DAO database properties (CurrentDb.Properties, create/delete), we query our own SQL Server backend, and in one branch we call Application.CloseCurrentDatabase().

Some customers report that Access databases on network shares occasionally end up in an inconsistent state and have to be repaired by Access. One user documented the sequence: while saving a query, the database closes by itself; on the next open, Access reports "Unrecognized database format", then repairs the file into a new database. We have not been able to reproduce it.

From your forum post at FID=1&TID=15391 we understand that Access has no application-level events and that Add-in Express simulates OpenDatabase, CloseDatabase, AccessIdle and CurrentObjectChanged by polling with a timer. That leads to four questions:

1. Can OpenDatabase fire for a database that is already open? Specifically: if reading CurrentProject.IsConnected or CurrentProject.FullName fails or returns an unexpected value in a single polling cycle — for example because Access is busy — does Add-in Express then raise CloseDatabase followed by OpenDatabase for the very same file, without the user having switched databases? If so, what is the recommended way to tell a genuine database open from such a repeated notification?

2. What exactly does AccessIdle mean? Does it indicate that Access is actually idle and not processing anything, or simply that a polling cycle passed without a detected change? We are asking because we would like to know whether AccessIdle is a safe moment to perform write access (creating and deleting DAO database properties) on the currently open database.

3. Is it supported at all to write to the open database from inside these event handlers? Our handler writes DAO database properties and, in one case, calls Application.CloseCurrentDatabase() directly from the OpenDatabase handler. Is there a recommended pattern for deferring such work to a point where Access is guaranteed not to be in the middle of an operation?

4. Can the Access polling be configured? Is there a supported way to change the polling interval, or to suppress the Access polling entirely if an add-in only needs OpenDatabase? Does setting ADXAccessAppEvents.Enabled = False stop the polling itself, or only the raising of the events?

Thanks in advance,
Norman
Posted 05 Sep, 2026 07:18:39 Top