First, Jiri's directions are good.
To add to Jiri's comments, note this fact: The references of which we speak are pointers to function, subroutine, symbol, and text libraries that define things for Access. So when you do what Jiri told you, you will see a complex dialog box with a list of names that often (but not always) include the word "Library" as part of their title. And sometimes the word "Object" as well. Can't hardly not recognize it once you see it.
The reference items being used by your app will have check-marks in the left column next to the item you are using, and this list is always sorted so that all checked items are at the time. The unchecked items are alphabetically sorted.
Things to look for: "Missing reference" will appear next to a name that is checked but for some reason that referenced library isn't available. This is also sometimes called a "broken reference." The error you are seeing is caused by broken references.
Why this happens? Several reasons!
1. An update from Microsoft has hosed the machine to tears. Rare but it happens. Since it is only on one machine, I'm disinclined to say that's your culprit.
2. (This applies because you are sharing the front end container.) The wrong version (an OLDER version) of Access is installed on the workstation assigned to the user having the problem. Access would automatically UPGRADE any old versions on a machine, so if the app was built on Ac2013 but run on Ac2016, it would upgrade to 2016 versions of the references. BUT the user whose machine is still on Ac2013 cannot then DOWNGRADE those references to match what is on his machine.
3. Corrupted registry entry - because references are stored in the registry even though the app includes a list of what it needs. So each machine is potentially different. It is rare to corrupt a registry entry these days - but it could happen.
4. Since you are actually sharing the FE file from a common folder, this can also be caused by temporary conflicts or permanent corruption of the FE. Usually caused by file locking issues.
Dave's comment (Gemma...) has to do with the way named function references are managed. Once VBA thinks there is something wrong with a particular reference list item, NOTHING will get past that item. But what happens is that the NEXT attempt to find an entry point (such as NZ) will ALSO fail in the specific case that the second entry point would have been satisfied by a later entry in the list than the failing one - because VBA can't get past that failing reference.
