OK, two things pop out at me:
First, that is a specific message from the ACE engine. It is a statement that the engine attempted something and failed to find whatever the name really was. That means that SQL is involved. It is not VBA trying to find something. It is SQL trying to find something. There are a few ways that can happen. I'll get to that in a moment. Further, if there really IS a dot in that name, it would seem to me that the first part of the name is the query name and the second part is the field name. As a sanity check, if that dot really is there, does the name to the left match the name of the report? If so, then the name to the right is all you need to find. If not, you might have found the problem right away.
Second, this happens when you try to launch a report. A single- or double-click on a report item doesn't make a difference if there is no code for the double-click. Access just converts that to a single click and carries on with whatever it needs to do next, so the absence of double-click code is no biggie. The execution of single-click code is also no surprise.
Even if the report was originally built based on a stored query, there might be some differences between the original query and what the report sends to ACE. Reports analyze the query so that they can impose their own ideas on the data, particularly if the report has grouping and sorting built-in. If the report's designer manually imposed sort or group options, that would be enough for Access to create an alternative query as the source of the data set. These would qualify as "hidden" queries so you might have to show hidden queries when trying to find the culprit. The name of the "alternative" query would have a tilde (~) as its first character and would resemble the name of the report.
The ways that SQL gets involved here would be either the actual SQL of the report's .Recordsource or as a quoted string in one of the arguments of a domain aggregate like DLookup" or "DSum" or "DCount" in a page header, report header, group header, or detail section on the first page. The criterion for a domain aggregate doesn't get checked until you actually open the aggregate function. Or you could have opened a separate recordset based on a quoted SQL string for some reason behind the scenes of the report. You should be able to search the report's VBA code for the string in question. Since it is related to the report, that really narrows where to look. If you can't find it in the VBA code, it isn't likely to be in any other function.
If the code search draws no result, then look at the form in design view and look at its .RecordSource - and if there is a sub-report as part of the design, it would be possible for there to be an error in the field name of the parent/child linking fields. The biggest chance is the main report's .Recordsouce. I would say that there is a chance that an automatically generated report would make the reference, except that if it was automated, the automation wouldn't select an invalid field. So this is PROBABLY the result of someone "adjusting" some element of the report's design or query.
