A bad day with Access, is it only me?

[twgonder]

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:

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)?

 

[cheekybuddha]

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'

 

[twgonder]

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?

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.

 

[cheekybuddha]

No, that code looks like (a really horrible way) to open a different database.

 

[twgonder]

And for "message" this is all I found in the same module:

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

 

[cheekybuddha]

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.

 

[twgonder]

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.

 

[arnelgp]

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.

 

[The_Doc_Man]

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.

 

[twgonder]

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.

 

[twgonder]

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.

 

[The_Doc_Man]

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.

 

[GPGeorge]

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.

 

[twgonder]

Did you try uninstalling and reinstalling Office?

I'm not going to do that just yet. It's a big pain since it's all downloaded over the internet, and not on a DVD anymore. I've only got limited bandwidth. Some of the people that are saying it's impossible for Access to touch Windows, probably aren't running the same version of Office Pro 2021 and all of its components, or they just went ahead and clicked allow when the Windows security message popped up the first time they saw it.

 

[The_Doc_Man]

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.

It may be the only case where some other error is triggering the reported error. We have no way of knowing without some serious digging as to whether ANY of the Office elements are passing back data, or how.

 

[KitaYama]

It's a big pain since it's all downloaded over the internet, and not on a DVD anymore.

When you access your account, you have the option to install office via internet or download the DVD.
You can select offline installer and keep a copy of it on a DVD for next installs/repairs:

Some of the people that are saying it's impossible for Access to touch Windows, ....... they just went ahead and clicked allow when the Windows security message popped up the first time they saw it.

Now are you telling us your install and settings are OK and it's normal for Access to touch Outlook? And it's all other several million users of Access who have not noticed it?

 

[twgonder]

When you access your account, you have the option to install office via internet or download the DVD.
You can select offline installer and keep a copy of it on a DVD for next installs/repairs:

View attachment 102308



Now are you telling us your install and settings are OK and it's normal for Access to touch Outlook? And it's all other several million users of Access who have not noticed it?

I try not to put words in the mouths of other people.
But thanks for the tip on how to get the download files. I'll fire that up some evening when I can get a good wifi connection somewhere.
But because I bought an online key, I'm not sure if it's in my M$ account, I give M$ as little of my data as possible.

 

[twgonder]

What do you think?

I was in a brand new db, none of the old code that I imported from forums was even in the db.
If it was some install problem, or other issue, how would Access even know to look in a folder that isn't the standard location for Outlook files?

 

[The_Doc_Man]

From that display, it SEEMS like someone didn't "trust" Outlook the first time it was started. Was the installation even done as Admin? It is fine to install private copies of executables. I do that all the time with my games. But for sharing, you would need to install EVERYTHING under "Run As Admin" in order to have proper interoperability.

 

[twgonder]

From that display, it SEEMS like someone didn't "trust" Outlook the first time it was started. Was the installation even done as Admin? It is fine to install private copies of executables. I do that all the time with my games. But for sharing, you would need to install EVERYTHING under "Run As Admin" in order to have proper interoperability.

I don't have a videographic memory. I bought a new laptop about six months ago. Did the standard updates and cleanups. Bought an on-line licensed Office Pro product key from a reputable source. Downloaded the install files. Microsoft did it's thing to install. All was done in an administrator account. The install indicated that everything went well. Only very rare problems with Outlook hanging or crashing for about four months. Two months ago I start using Access. Problems start. It's possible that the install files were corrupted by some kind of malware that wants to steal my contacts or some such thing, but those install files came directly from Microsoft, so I rule that out as highly unlikely. Much more likely is that the Office suite is trying to communicate from one module to another. Even the Microsoft Protection history gives it a "Low" level of threat.

The message, as I see it, is indicating that it is MSACCESS.EXE that is being blocked from the protected folder where I keep my .pst files. Now, as I've been asking over and over again, why is MSACCESS.EXE trying to get to my .pst file? Forget install issues, forget timers and mail stuff that isn't even in a new .accdb file. They aren't relevant, to my way of thinking (which may be wrong I know), to what the security message is trying to say. ACCESS WAS BLOCKED FROM GETTING TO A FOLDER WHERE OUTLOOK FILES RESIDE. I have no files in the Outlook folder other than .pst files and an old registry save that should be of interest to Access.

Maybe many of the commenters haven't put their .pst files in a documents folder for security and backup? Maybe they don't have Ransomware protection turned on to protect where they do have their .pst files? Maybe they don't have the Office Pro 2021 version that I have with all the updates? This is most likely an internal question about a black-box application called Office that has installed 8,760 files at over 4GB. Does anybody really know for 100% what is going on inside that black-box? I don't, but I think I understand what that security message is trying to say. There is code inside Access to work with Outlook, why presume this error isn't part of that whole bit of code in Access? If this is the case, then reinstalling or digging deep into system logs isn't going to change this unless Microsoft has removed the "feature" or fixed a bug. In either case , then my Office updates should handle that issue. My past experience tells me not to reinstall for such a trivial question, as the reinstall often causes more problems than it fixes when laid on top of existing files that are based on newer updates over six months.