Back in post #8 you posted a screenshot of your code
Here is a screenshot of that screenshot! (In future please copy the code itself)
In post #10, I explained your error.
To repeat, you have a function called GoToJob so the next line must start with GoToJob.
Using GoToRow will fail because that's not the function whose value you are trying to return
Similarly the next function GoToNCR. The second line MUST start with GoToNCR
I agree with comments about a timer event being thelikley cause of erratic behaviour
In a way, your approach is SIMILAR to the way that the ALGOL language and a couple of other OOP languages would "overdefine" a function. I think Pascal language does this too. The alternate subs call the same active routine with different input arguments. This is similar to overdefining a function to do something when the argument is type X and something slightly different when the argument is type Y. So I kind of understand the strategy. That SHOULD work for Access.
Usually this kind of problem is a corruption issue. Post #8 says you exported everything to another fresh DB, which should eliminate corruption. Did you get any errors when you did that? AND did everything you intended to import actually show up? (I know that you reported that the compilation error persisted, but I'm talking about errors during the export process and errors of failing to copy something.)
JHB's comment is important. When Access says Function or Sub not found, that is unequivocal. You claim that GoToRow is defined as Public in a General Module. I want you to run a quickie experiment. It will be simple.
Get to a VBA editing page. Open Object Browser. Select "<all libraries>" in the library selector and then type in "GoToRow" in the search box. Click the search (binoculars) button. How many times does GoToRow show up?
The answer will be 0, 1, or (maybe) 2 or more. If ZERO then that name isn't visible. If 1, then it should be listed as a Sub entry in your project. If MORE than 1, you have a keyword conflict.
From the VBA editor, don't try to compile - but DO try to search (the entire project) for every occurrence of the GoToRow string. Use the Whole Word Match option but the Match Case option is not required. Verify that you have one and only one definition of the Sub entry point and verify that the entry point is spelled exactly the same way as the references to it.
OK, here is the "big gun." Be sure that whatever you are doing, you have a system clock time visible, perhaps at the lower right of the screen in the Windows Task Bar. Now go through the process that causes Access to crash. IMMEDIATELY note the time of day. It is usually enough for it to be accurate to the minute.
Now use the Start Button to get to the Detailed Control Panel to run Administrative Tools. Find the Event Viewer and open it. In the navigation panel to the left, you will have several logs - system logs, application logs, possibly device logs, possibly security logs, and sometimes there are specialty logs such as Office logs. (The latter is rare - but possible.)
One by one, go through the logs, which are sorted by time with the most recent time at the top of the list (so Ctrl/HOME will jump-scroll there). Look for a logged event relating to MSACCESS.EXE from the time of day of that contrived crash. Also check for device errors like disk or memory errors. (The latter would be EXCEEDINGLY rare.)
Whatever you find, if related to this event, should be in the same minute that you noted when the crash occurred because system logs and the time display in the task bar BOTH get their times from the system internal date/time clock. If you find one log, don't stop there. Look through all the logs for something at that specific time. The text of the error will tell you which library module and which executable image failed. There will be an "Exception" code as well.
If you find something in the event log, you should be able to do a cut/paste on the text. If so, bring it here.
Thanks to all of you, I have made some progress. I installed V-tools and did a deep search on the GotoRow sub. I found it in 3 different forms. I'm not sure why it was there - this is an inherited system and I saw no evidence the code was even in use. So I commented it out everywhere I found it. I will test and make sure nothing has stopped working but for now it looks like it was just abandoned code.
Then I went through and set everything to Option Explicit and tried to compile. Everything that it stopped on was an undeclared variable. So I fixed those one at a time and was able to get all the way through.
After that, I did a compact and repair. So, the VBA editor seems to be working again and Access is not unexpectedly closing on me (at least it hasn't in the last hour or so.
I'm still searching for a reason for the run time error I mentioned earlier when running a report for November data. It makes no sense that it wouldn't be able to evaluate dates after 10/31/18.
But, at least I can debug now and that is no small thing.
Thanks to everyone that contributed advice. I appreciate it.
Interesting that you found it in three forms. The question is, was it in the form's class module for the form you were editing that led to the crash? Scoping rules suggest that the closest thing wins, so in a form containing a GoToRow sub entry point, the Public version in the general module SHOULD not have been visible.
The report problem could have been a myriad of things, given that you had errors of the type that were detected by adding Option Explicit. The report crash COULD have been totally unrelated to the other problem. If you stick with Option Explicit and fix the GoToRow issues, you SHOULD have smoother sailing ahead. Good luck!