You might have to search the forum for references, but there are such things as code analyzers. Some commercial products exist, but I rolled my own for the learning experience that it represented. Then the darned thing turned out to be useful. Before you ask, it was work done for hire for the U.S. Government, and I don't own it so can neither give nor sell it to you.
I'll tell you how these analyzers work. You HAVE to understand string parsing for at least some parts of this and should have a grasp of finite automata theory so you can avoid building a non-finite automaton.
In essence, you run discovery loops through every collection in your database - Tables, Queries, Forms, Reports, Modules. Don't know that macros CAN make a reference. These loops take the form of a "For Each <formal-object-name> in <collection>" ... "Next <formal-object-name>". Look up "VBA Collections" or "Component Object Model Collections" to see explanations of collection discovery.
For tables, you find one FieldDefs collection for each table and run a discovery loop to capture the name and other attributes of the fields. There is also the mSysRelationships table (a system table that is normally hidden, but you can safely read it) as a place where a field could be referenced. (Actually, TWO fields, one on each side of the relationship).
For queries, you find each QueryDef and look at its SQL, which will give you strings that can be parsed to find fields & tables. Both action queries and SELECT queries have a .SQL string property that should be parse-worthy.
For forms and reports, you find the .Recordsource, which will either be a named query or an actual SQL query. Again, parse. Then enumerate the controls. For those that have a .ControlSource you can remember the name. For those that have a .RowSource, more SQL to parse. Note that both forms and reports can have Sections which is itself a collection of segments that can contain collections of controls. Sections cannot, however, directly reference a field (I think) so the only thing to remember is in which section a given control was found. Don't forget that a form or report can have a Class Module (in which case the form/report .HasModule property would be True.)
I'll skip Macros because most of us don't use them, but I believe they involve text. So you MIGHT find queries with a RunSQL action or functions for a RunCode action.
The named general modules are sequences of text strings in the .Lines
collection. The same is true for the Class modules from forms/reports that are accessed through the .Module property of the form/report. Each string in a module has a line number relative to line 1 at the first line of the module. You can parse each string to see what it has in it. Line numbers can (& do) start over again for each module.
Why do all of this? You can do INSERT INTO for a table in which you store the name, where you found it, and whatever properties you can determine. You have to like parsing to make this work right, but it IS workable. When you are finished, you can write a report that steps through the object tables to show name, reference, attributes, etc.
A reference is either a DEFINING reference (FieldDefs in a TableDef or field alias-names in a QueryDef), DIM statements in class or general modules, formal arguments in SUB or FUNCTION statements, etc.; or a USING reference (fields in any query's SELECT list or other syntax (WHERE, ORDER BY, etc.), or in a form/report as a .ControlSource or in a .RecordSource or .RowSource SQL statement, or in a VBA statement that at least appears to be an expression containing a variable name.
I do not recommend the above approach for beginners, but if you choose to do this, when you are done you will know the structure of Access COM elements to a level of detail you really didn't think you ever wanted to know.
