Hi Jennifer

What kink "behave differently" is the customer reporting?

In a recent instance, the database was supposed to ask the user if they wanted it to do something. I have a screen recording from the user and can see that it did not do so. When I duplicate the user's actions in the recording on my computer, the database displays the message box correctly, asking me if I want to take the action.

When I duplicated the user's actions on my computer, I noticed that it broke into the code and displayed but didn't highlight a line of code. There was no error message or indication of why it displayed the line. I pressed the 'runsub' icon in the code window to continue, and it continued without hesitation or error.

Are they using the same db version?
No updates been made recently that they don't have?

Hi, Alex Hedley. The user says they installed my latest update for the front-end database'one with recent changes. Of course, it's always possible they got confused and didn't correctly install the update, but I doubt it. I think they are using the latest version of the DB.

I believe Alex is asking about Access Version not your application version.

The following image is my version of Access

Thanks, Sami. Checking.

No I was asking about the db not the Access version
(Although it's possible that could cause problems it's more likely the other)

This is my client's Access version. I will now upload mine.

I also checked with my client about the General tab in Options in the VBE's Tools menu, and our settings in the General tab match. (Under Error Trapping, Break on Unhandled Errors is checked.)

You need to look at the *code* that performs the action you see but your user doesn't see.  Check why the code runs for you but not for your user.  Maybe conditions are involved.  All code in VBA is event-driven.  Maybe your user somehow can't trigger the necessary event but you can.  Can data affect conditions and criteria, which in turn affect whether certain code is run or not?  These are all possible things to look into.  In short, look at your code.

Do you use autoexec macros in your app?  The user can cancel autoexec macros by holding Shift while opening the app.

I have crazy things happen all the time, works one minute and then never again. Often, it's my code which has some undiscovered ancient bug, but just sometimes... I reboot, obviously start Access again (after a reboot), and often the unexplainable problems go away. Worse case so far, I have to reboot, recompile all the VBA code and reboot again! (Richard has a video on this, search for "compile" in TechHelp). Is your user running an .accdb or .accde file? Was there something in your recent update that could possibly affect this bit of code running or not? Does this code run or not run based on some data configuration, if so, is their BE data up to the most recent release of the Frontend (assuming they have the most recent FE)?

Thank you to everyone who considered my problem and weighed in. I will keep investigating this, and when I figure out the cause, I will post it here in case it helps someone else.

@ Jennifer (again), I have also noticied the behavior you descibed in post #4. Can you tell us what exactly the error said? For me, it usually involves some kind of VBA SQL error that sneaks through the cracks if F5 is pressed. Without the correct SQL recordset, a host of cascading logic errors often result.

@ everyone, you might also want to consider this little trick if you have some kind of startup or login form. I have control records with fields in "control" tables for the FE and BE. The "version" number (a long integer) in the FE and BE have to match or it's a no go. This helps keep the version questions at bay, so the developer can then focus on the offending code or other problem.

There was no error message or any indication of an error, but the odd thing is that it stopped executing at a certain point for no apparent reason. It was as if I had set a breakpoint there. The place where it stopped was where I called another procedure inside an If/Then statement.

@Jennifer for the post above begins with "There was no error..."
I've seen that situation in at least two situations that I can recall the specifics of.
1) A break point was once set at that line, and it somehow remains even though the "red dot" isn't showing in the VBA editor. For me, before I send out a FE, I Ctrl+Shift+F9 in VBA editor, Compact and Repair Database, decompile, compile, and then immediately make the .accde or save the .accdb and don't allow any changes to the VBA code.

2) As Kevin suggested above, for a procedure that has some kind of error, sometimes a late-binding (I'm guessing this is the correct name for the situation, I haven't dug too deep into the different bindings) variable not defined and it's not caught by the Compile, or a run-time error dealing with the SQL code just throws up a non-stopping-error message, or not depending upon certain control settings or on error settings. In this case, I've found no other option than to find a breakpoint just before the error occurs, step line-by-line through the code on the user's machine (they probably have some weird data issue you didn't anticipate). This brings up another issue, if the user uses an .accde you'll need some policy that allows you to connect to their workstation remotely and then do the steps with a .accdb that you have control over (maybe with password or Window's account/permissions?).

Thanks for your comments, Thomas. Regarding point 1), I'm unsure how to "decompile." Can you please explain? Regarding point 2), how would you suggest connecting to their workstation remotely? They are in another time zone using a laptop and running a split database, both of which are accdb files.

Decompile is done with the command line. I can't remember the last time I had to do that as well but they're both in these videos, Compact & Repair and Compile

There are tons of remote programs available. You would need some kind of software to do an unattended remote session. But if the user is there on the other side to let you in, you could use something free and easy like the built-in Windows tool, Quick Assist

This is the point at which I start running down the Troubleshooter checklist. Sometimes dumb things can cause huge problems. I once had a database that wouldn't load properly because the customer had a fault in his keyboard.

HIS KEYBOARD!

A hardware problem was causing my software to not load right. Replaced the keyboard, problem went away.

That kind of issue can be discovered by having the user try another PC, which is I would suggest Jennifer's customer do.

Absolutely.