Most of my customers that I build Access apps for have not been Access users. In other words, they tend to know very little about tables or queries or reports, design view, VBA modules and macros.

This tends to make my job easier in that I don’t have to be concerned if users decide to add queries, modify designs on reports, etc. My system is generally to create front ends for each user of the app which generally runs one instance for a single user. When I upgrade it, I just copy a brand new front end up and their app updates each user’s front end.

Recently I had a customer who is an Access feature user. They modify their data by directly editing tables and create queries in their shared database and direct the other users to look at their queries they created.

After upgrading them to begin using a new system for their database that other departments were using, they noted that the subdatasheet that related the Family table to the PartNumber table was no longer there.

Subdatasheets are automatically used for local Access tables, but I had moved the tables and linked them from the new back end. It turns out that the auto feature doesn’t work for linked tables, but you can still use this feature by creating local queries and the subdatasheet feature can be used there. This will work for local and linked tables even if you are linking to a non-Access backend.

In order to do this, you need to create a single query for each table (I created FamilySubdatasheet and PartNumberSubdatasheet queries, one for each table).

Then in the query properties in design view (on the main parent table) you can select the child query (PartNumberSubdatasheet in my case) and then the child and master link fields. Then when you go into the datasheet view on the query you will have a plus sign you can you to expand a row and see any child records in the related table.