FUNCTIONS NO LONGER WORKING IN ACCESS

Now, this is going to be a dumb question, but I just want to clear the air on it so that we can move on.  You have created a Trusted Location for your database front-end?

My first guess would be you are affected by https://www.devhut.net/2018/10/31/ms-access-bug-vba-code-doesnt-run-as-accde/.  This seems to be more and more an issue where it never used to be.

Let's set the blame game aside for a while and focus on what you CAN do.

That includes modifying your startup code along these lines.

Let's assume you already have an AutoExec macro that starts the app. If not, you need one. No startup form.

That macro is a one-liner and will use RunCode to call one new function in a new standard module. Let's call it CheckReferences in modReferences.

Everything written in that module, including every procedure it calls, must be written with 2-part function calls, so 

Dim ref                 As Access.Reference

rather than

Dim ref                 As Reference

Access.DLookup

rather than

DLookup

etc.

In that function you loop over the Access.Application.References collection, checking each one for IsBroken.

If you find one, use its Guid to DLookup its name in a new table in the FE (NOT in the BE - at this point we have not even connected to the BE) and display to the user and quit.

The new table is populated with at least Guid, RefName, and RefPath, using another new function in the same module. Before you deploy any new version you re-run this function.

This will allow you to check references at startup time, and only if it passes this test you will call your normal startup function. In my case modInitApplication.InitApplication.

Of course you also have to compile your ACCDE in the lowest version of Access that your users may have. Having a clear picture of what everyone has installed is important data that you really want to have. If you have references to other Office applications or 3rd party apps you want to know those versions as well.

Tom –

Questions re the new table:

Why use a new table when the guid, path, and name of a reference is contained in the References collection? (I hypothesize, since one of my references has no guid.)

And isn’t that going to be erroneous information, since the link is broken?

Thanks for sharing.

It is possible to use different versions of Office, but I have found as well that it may not work on every workstation. Never had enough time available to chase it down. Compiling on that machine would work so we moved on.

Glad you got it to work and thanks again for sharing your solution.

You get into those types of errors when you try and use a database on an older version that it was previously run.

You see, say you developed a db in 2007, then it gets run by a user in 2013 and later, a 2010 user goes to use the database, they will get these types of errors.  When opened in 2013 Access automatically upgraded the reference to 2013, so when you go to 2010, it no longer works.  This is why it is crucial to do all development using the oldest version that will be used to run the database and deploy a personal copy of the front-end to each user (no sharing of a common front-end can be permitted).