Object Dependencies Missing

[Pooks_35]

This morning two tables were deleted from a database. The database failed to back up over night but I was able to import those two tables from a previous version of the database. My question is, looking at the object dependency between these old and new versions of the database, it appears the new database is missing some of the tables in the list of the object dependency for each of these imported tables (all the queries and reports are showing in the list in the current database, just not the tables). However it appears everything is working. Should I be concerned about this? If so, I do I import these two table to ensure all definitions are imported with them?
Thanks!

 

[jdraw]

Have you done a Compact and repair?
Why did the backup fail?

 

[Pooks_35]

I hadn't tried the compact and repair, just did and those tables still don't show in the object dependency.

The backup failed because the company that is suppose to take care of our server set up everything on the server to back up, but of course, missed a critical item, the database.

 

[jdraw]

Someone in your company tests and verifies that the procedure to do the backups etc works to the agreed the level of quality. Somehow this fell through the cracks. How long has this been in "production"?
It would appear that your company and the one responsible for backups etc have not done thorough testing.

 

[The_Doc_Man]

I'll take a crack at a simple answer for your "Why are the dependencies not there?" question.

When you re-imported the two tables that had gone missing, you probably imported them with different internal object identifiers, which appear in the hidden system MSys table. (DON'T go mucking about trying to reset the numbers in MSys - it is hidden for a very good readson.) I believe the Object Dependencies depend on the internal numbers, but in your case they changed and are "obviously" different tables.

To restore these dependencies (if you know them all), open each item you THINK should depend on one or both of those tables. Find the point where the child object references the table. If it is a table drop-down selection (which occurs when the table is the recordsource for a query, form, or report), just reselect the newly imported table of the same name as the one you used to have there. In your case, the fields are the same and the layout is the same, so Access will refresh the dependencies. This is one of the ways to repair bad linkages that falls just short of doing a full-blown compact and repair operation.

Note that you won't have static dependencies on VBA-created dynamic strings, I.e. strings created in VBA and then executed by a DoCmd.RunSQL or a DAODB.Execute method. Those are dynamic query dependencies that won't show up in the Object Dependencies page.