Is "Object Dependencies" reliable?

[gar]

I deleted a query on which, according to "Object Dependencies" nothing depended but errors in my final report immediately appeared. I restored the query from backup and normal service was resumed. Is "Object dependencies" known to have deficiencies or have I overlooked something?

[Micron]

I'd say you overlooked the fact that the report depended on the query and not the other way around. After being restored, what does the dependency show for the report? It should have at least 1 by the sounds of it - the query. I have not used the dependencies reporting too much but when I did, it all looked correct. The trick might be knowing what to look for. What this does point out is why I rename an object I think I no longer need and wait for a period of time for some problem to arise before deleting it altogether. By putting zz in front of its name, it also stays at the bottom of my list, out of the way.

[isladogs]

I agree. Good advice from Micron
Object dependencies are reliable apart from the items stated as being specifically excluded

Remember these facts as you use the Object Dependencies pane:

• Dependency information is available only if you have permissions to open an object in Design view.
  
• The pane does not show information for macros and code modules.
  
• The pane works only for tables, forms, reports, and queries, except for the following types of queries:
  
  
  • Action queries — queries that insert, update, or delete data
    
  • SQL-specific queries, including union queries, data-definition queries, and pass-through queries
    
  • Subqueries
    When Access encounters nested queries, dependency information is generated only for the outermost query. This rule also applies to the source tables and queries of a query's subdatasheet, and to lookup fields.
  
  Note: In these types of cases, Access generally lists these objects in the Object Dependencies pane under the heading of Ignored Objects > Unsupported Objects.
  

[gar]

Thanks for your reply - After restoration, Dependencies indicates, of the report, that it is not dependent on the query and, of the query, that nothing is dependent on it. The relationship between the two is that the report contains a control which uses "Dsum" to obtain the sum of the values in one of the columns in the query. Perhaps this is a type of dependency which Dependencies does not recognize. - Renaming an object is a technique which I have employed in such contexts before but use of the "zz" prefix is a good idea which had not occurred to me.

[Micron]

that it is not dependent on the query

You are saying that the only link between the query and the report is that one report field is calculated and the calculation expression refers to the query? Then I believe you are correct - the report would not show up as being dependent on the query because that determination is based on the record source property of the report. However I do believe the control would show up in the database documenter for the report and show the DSum expression for that control.