So, I started another instance of Access, opened a different .accdb.
Got ready to quit for the night, switched over to Access, got my emails, and then this came up:
View attachment 102286
I haven't done anything, or loaded any sample .accdb that do anything with mail.
Now tell me again how Access doesn't do anything to Outlook unless I tell it to.
That file called out in that little message also includes a "Namespace" object that can be opened via recordset operations. Look for "Namespace" and "Attachment" with your whole-project search. The form of that message suggests to me that you have a recordset open to the .PST file with some option OTHER THAN dbSeeChanges, so you are being notified that the recordset source changed while you had it open and thus you have to manually refresh the connection.
This will seem pointless, perhaps, but it is not. There is a way to confirm that you have a .PST file open and that it comes from an Access task. You can use normalized windows for this. Open the Access DB that exhibits this problem. Set it up so that if you did some particular thing, it might exhibit the original problem - but don't actually do that something. Now shrink the window so that it is open but not more than 1/4 of the screen.
Next, open Task Manager. Select the Performance tab. At the bottom, click the option to open Resource Monitor. That option ONLY appears under the Performance tab so don't look for it elsewhere. In RM, select the Disk tab and look at Disk Activity. This is the tedious part. Scroll through that, perhaps by "grabbing" the scroll bar to the right. Find that file, which if I am right in my guess, SHOULD be open at this time. If so, there is a PID column and an image column. (If not, right-click on that heavy divider bar to see if there are hidden columns. Unhide them.) If Access has the .PST file open it will show up there in RM. This would confirm beyond any doubt that something is actively looking into the post-office file.
EDIT: Of course, Outlook will have one or more connections to this file as well. You want to see an Access connection to prove the point.
IF this Access connection is confirmed, then go into the VBA Code window. Set a breakpoint behind something that executes at least one line of code so that you can set that breakpoint. Now do whatever will cause that code to be executed. When it takes the breakpoint, open the Locals Window from the Menu bar. This will get very tedious but if you are careful, you can nail this.
In the locals window when in debug mode with code stopped, there will be the item
[+] Me, and probably very little else unless you have some things defined PUBLIC in the module's declaration area. Click the + sign to expand the item, which will be a big tree view. Each time you click on a "+" to open an item, a branch of the tree will open.
Look for [+} Application. Expand that.
Scroll down to find [+} DB Engine. Expand that.
Scroll down to find [+] Workspaces. Expand that.
It is a short scroll to [+] Item 1. Expand that. (It is your local Workspace object.)
Scroll down to find [+] Recordsets. Expand that.
Each item under Recordsets will tell you the name of the recordset that is open and will identify other information about it such as its source, which will be a table, query, or (in rare cases) a filename. This might be enough information for you to find what has that file open because it will include the correct name of the recordset variable among the other information under each Item.