A bad day with Access, is it only me?

I had two Access Windows open (by accident,) but I do sometimes for copying. When I shut one of them down the "Unauthorized changes blocked" notification popped up. Hmmmm

The easy solution is to just allow Access to "change" whatever it wants to do to Outlook, but the question again, why is Access doing this? I doubt it's an installation problem, the error would be much more severe I would think. I really don't want to start uninstalling and installing again. If it's a serious problem, I hope MS will figure it out with a patch. The bigger question yet is why HP and others allow MS to preinstall 365 if it's going to cause problems with other installations of Office later (if that is the reason)?
 
Last edited:
Have you considered a clean re-install of all Office products?
Everybody is telling you Access doesn't do that sort of things and if you see something weird is going on, apparently there's something wrong with your install or setup.
There's an app on MS support site for this purpose.

If it was me, I would do a recovery of Windows from an image. It would take only 20 minutes and I would be on my feet again, clean and fresh.
Well yes, I could go back two months and do a restore...for this simple problem, Um no.
 
I had two Access Windows open (by accident,) but I do sometimes for copying. When I shut one of them down the "Unauthorized changes blocked" notification popped up. Hmmmm

Keep track of which one was opened first. Do the experiment of seeing whether, starting from two Access windows open, it is the first-opened instance or the second-opened instance closing first that triggers the notification. (This is a test for locking issues and lock conversion.)
 
Keep track of which one was opened first. Do the experiment of seeing whether, starting from two Access windows open, it is the first-opened instance or the second-opened instance closing first that triggers the notification. (This is a test for locking issues and lock conversion.)
I should probably put this in its own post, with more of an explanation. However, it just came up with this problem. For my synch plans regarding Home and Remote back ends (in another post that got out of hand), I've thought of having one remote computer (like the last sales workstation--least used) run both Fe and Be at the same time (the Be running to log changes and send them to home for synching while the Fe does the sales task.) I've been mapping it out in my head. But I gotta ask, is there anything knowingly "wrong" with running two instances of Access on one machine at the same time?
 
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:
1659765919483.png


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.
 
To answer post #44, I often have several instances of access open at the same time without a problem.

but if the first instance has an active reference to the second instance, the second instance will be locked for design changes

as for your main issue I don’t think anyone here can offer any more insight or suggestions as to why that is happening as nobody else appears to have had the same experience . If it was due to a ms update or a wrong install I would expect there would have been multiple posts on this and other forums

nearest I could find was this 10 year old thread
 
Okay, I woke up and thought (with a little more clarity thanks to sleep), maybe I was premature in my suspicion that it is Access doing this on it's own. There is one alternate possibility. Several weeks ago I downloaded a sample database dealing with handling multi-language.
How to implement a multi-lingual database - Microsoft Access / VBA (bytes.com)

I copied out bits of the code and started testing my own multi-language app. Maybe, just maybe, some portion of his code that escaped my less-than-eagle-eye for Access stuff missed something in his code that touched Outlook. It seemed not likely since the code is several years old but who knows?

So I went back to the original .accdb, and did a search for anything "Outlook" in the project. Here is the result:
1659784505020.png


If that code (that I partially imported into my app) was to touch Outlook in any way, can you think of something else to search for besides the text "Outlook"?

At this very moment (as I'm here typing), I've got two instances of Outlook running, one with a freshly minted new .accdb. And then for writing this, the sample multi-language database. And while I was typing here, I saw a notification about "Unauthorized changes blocked". Could this be one of those infamous timer things that some people have mentioned? How can I now go see if that sitting there, doing nothing sample.accdb is actually trying to do something through a timer (or other way)? In other words, with all the code in that project, how can I locate a "timer" that might be secretly running without my knowledge?

When the word "timer" is used, I presume it is some code that occasionally wakes up to do some task, and then goes back to dormancy. Is that a valid presumption (since I have yet to study "timers" in Access)?
 
Last edited:
how can I locate a "timer" that might be secretly running without my knowledge?
Timers are attached to forms - they will only run if the particular form is open. Close all forms and no timers will be running.

To check if a form has a timer attached check the OnTimer property in the events tab of its property sheet. If it is empty then no timer.

can you think of something else to look for besides the text "Outlook"?
Search for 'send'. Also 'msg', 'message', 'mail'
 
Timers are attached to forms - they will only run if the particular form is open. Close all forms and no timers will be running.

To check if a form has a timer attached check the OnTimer property in the events tab of its property sheet. If it is empty then no timer.


Search for 'send'. Also 'msg', 'message', 'mail'
Here is what I found for "send" in one of the VBA modules, The form wasn't running, but I see the code stops it, so maybe we're onto something here?


Code:
Function LoadNewDBS()


    On Error GoTo Err_LoadNewDBS
    Dim lngTime As Long
    DoCmd.Close acForm, "fmnuMainMenu"
    DoCmd.Hourglass True
    lngTime = Timer: While Timer < lngTime + 1: DoEvents: Wend
    SendKeys "%FOc:\Education\Translate.mdb~", False


Exit_LoadNewDBS:
    Exit Function
Err_LoadNewDBS:
   MsgBox Err.Description & " in LoadNewDBS"
    Resume Exit_LoadNewDBS
End Function

Does that sendkeys look like it could touch Outlook?
Some of the code is so foreign to me, but it's a good learning example.
And if it does somehow touch Outlook, I still need to find why it crashes Access and Outlook.
Isn't debugging someone else's code without comments so much fun? (But I'm learning a lot)
I'll keep searching for the other phrases.
 
No, that code looks like (a really horrible way) to open a different database.
 
And for "message" this is all I found in the same module:


Code:
Sub MESS(varText As Variant)


'   Author Mark Fisher
'   Description
'   ???
'
    On Error GoTo Err_MESS
If varText = "OFF" Or Len(varText & "") = 0 Then
    DoCmd.Close acForm, "fdlgMessage"
    DoCmd.Hourglass False
Else
    DoCmd.OpenForm "fdlgMessage"
    Forms!fdlgMessage!lblMessage.Caption = vbCrLf & varText
    DoEvents
End If


Exit_MESS:
    Exit Sub
Err_MESS:
    MsgBox Err.Description & " in MESS"
    Resume Exit_MESS
End Sub
 
I don't think that's it either.

You have a form called 'fdlgMessage'.

It looks like it is used a custom MsgBox, but that is just a guess.
 
I don't think that's it either.

You have a form called 'fdlgMessage'.

It looks like it is used a custom MsgBox, but that is just a guess.
Mark has tons of stuff in there, I have no idea what he's trying to do in all of his app. I was just looking for the ideas for implementing multi-language. I pluck what I need, rewrite what I have to, and ignore the rest. I do have his module with this code in my test .accdb, so it will run for the moment.

The downloadable .accdb is available in the bytes.com article I linked to.
 
I was just looking for the ideas for implementing multi-language
i have done translation long time ago.
on this demo, the "user" is common, "pass" is common.
click the Search and View on the ribbon, a form will open.
if you look at the "Datasheet tools" on the ribbon, you can switch between english, finnish or swedish.
you need to use Shft key while the db open for you to see the codes.
 

Attachments

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.
 
Last edited:
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.

IF this 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, there will be the item [+] Me, and probably very little else. 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.
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.
It's a plan, after the nap.
 
I was sidetracked by a little demo I got showing how to use function keys in a macro. It only had two tables, maybe ten lines of code. After playing around in the demo, I closed Access, and bang, the unauthorized changes blocked message. After that I couldn't download emails until I restarted Outlook.

So far, the error has happened 5 times today, and there is no way this little demo .accdb did timers or anything else to Outlook. Sometimes, when Access closes, in my version and laptop, it tries to "reach out and touch" Outlook. I'm 98% sure of that.
 
Because of the rules that Windows lays down, Access cannot do that on its own. Rules having to do with inter-process independence. That is to say, "reaching out and touching" Outlook just because "it feels like it" - cannot happen. I'm not doubting the touch. It just cannot be spontaneous unless (a) something is broken or (b) something hidden is going on in your code. There will be no (c) Access has a wild hair.

However, having said that, it occurs to me that this might be something actually in Access itself. I have to ask my colleagues to chime in on this one, because I have never used O365.

Since O365 version involves a yearly lease, is it possible that leasing information is somehow being forwarded to MS from a remnant of O365? And now that we've opened THAT can of worms... does the newest version of Access ask if you want to participate in improving the product by allowing it to send MS some information on performance and/or usage? I know my Kaspersky and Firefox ask me that question.

FYI, both of these fall under the (b) case above - a hidden feature that would have been enabled by the way you did the install and the product that you installed. I've never seen that in Access but then again, I have an older version of Access.
 
Because of the rules that Windows lays down, Access cannot do that on its own. Rules having to do with inter-process independence. That is to say, "reaching out and touching" Outlook just because "it feels like it" - cannot happen. I'm not doubting the touch. It just cannot be spontaneous unless (a) something is broken or (b) something hidden is going on in your code. There will be no (c) Access has a wild hair.

However, having said that, it occurs to me that this might be something actually in Access itself. I have to ask my colleagues to chime in on this one, because I have never used O365.

Since O365 version involves a yearly lease, is it possible that leasing information is somehow being forwarded to MS from a remnant of O365? And now that we've opened THAT can of worms... does the newest version of Access ask if you want to participate in improving the product by allowing it to send MS some information on performance and/or usage? I know my Kaspersky and Firefox ask me that question.

FYI, both of these fall under the (b) case above - a hidden feature that would have been enabled by the way you did the install and the product that you installed. I've never seen that in Access but then again, I have an older version of Access.
I can't imagine a circumstance in which Access -- regardless of version -- would spontaneously reach out to Outlook. I'm sure MS 365 is contacting MS servers to verify current status of the OFFICE license. I can't imagine why that would invoke the local install of Outlook. But then, this is the only reported case where it seems to be happening that I've seen here and on other forums, so it's not like a lot of people are digging into it.

I believe the "opportunity" to share usage and performance information is ubiquitous.
 
Last edited:
Did you try uninstalling and reinstalling Office?
 

Users who are viewing this thread

Back
Top Bottom