SOLVED

Creating a relationship between one main table and two sub-tables

%3CLINGO-SUB%20id%3D%22lingo-sub-2192233%22%20slang%3D%22en-US%22%3ECreating%20a%20relationship%20between%20one%20main%20table%20and%20two%20sub-tables%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2192233%22%20slang%3D%22en-US%22%3E%3CP%3EHi%20Everyone%2C%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EI%20am%20creating%20a%20client%20database%20using%20access.%20I%20have%20a%20main%20table%20%22Contacts%22%20which%20includes%20my%20clients%20and%20their%20information.%20I%20also%20have%20two%20other%20tables%3A%20criteria%20A%20and%20criteria%20B.%20The%20two%20tables%20have%20different%20column%20titles.%20In%20my%20Contacts%20table%2C%20the%20primary%20key%20is%20the%20contact%20ID.%20There%20is%20also%20contact%20ID%20in%20both%20criteria%20A%20and%20criteria%20B%20tables.%20I%20linked%20them%20as%20a%20one-to-many%20relationship%20(each%20contact%20can%20have%20several%20rows%20of%20criteria%20A%20and%20criteria%20B).%20As%20a%20result%2C%20in%20my%20Contacts%20table%2C%20when%20I%20click%20the%20little%20%22%2B%22%20button%20on%20the%20left%20side%20of%20each%20row%2C%20I%20can%20see%20the%20criteria%20A%20table%20bounded%20to%20the%20contact%20name.%20However%2C%20I%20cannot%20see%20the%20criteria%20B%20table%20anywhere.%20Vice%20versa%2C%20I%20would%20only%20see%20the%20criteria%20B%20table%20under%20each%20contact.%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EPlease%20let%20me%20know%20how%20to%20fix%20this%20and%20if%20there%20is%20a%20better%20way%20to%20plan%20this.%20Thanks%20so%20much!%3C%2FP%3E%3C%2FLINGO-BODY%3E%3CLINGO-LABS%20id%3D%22lingo-labs-2192233%22%20slang%3D%22en-US%22%3E%3CLINGO-LABEL%3EAccess%3C%2FLINGO-LABEL%3E%3CLINGO-LABEL%3EOffice%20365%3C%2FLINGO-LABEL%3E%3C%2FLINGO-LABS%3E%3CLINGO-SUB%20id%3D%22lingo-sub-2192489%22%20slang%3D%22en-US%22%3ERe%3A%20Creating%20a%20relationship%20between%20one%20main%20table%20and%20two%20sub-tables%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-2192489%22%20slang%3D%22en-US%22%3E%3CP%3E%3CA%20href%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fuser%2Fviewprofilepage%2Fuser-id%2F989985%22%20target%3D%22_blank%22%3E%40EricTao%3C%2FA%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EWhat%20you%20are%20describing%20is%20actually%20NOT%20a%20really%20helpful%20design%20feature%2C%20as%20a%20matter%20of%20fact.%20I'll%20get%20back%20to%20this%20point%20after%20explaining%20what%20it%20is.%20This%20is%20what%20is%20referred%20to%20as%20%22Subdatasheet%22.%20It's%20a%20feature%20of%20Access%20which%20APPEARS%20to%20be%20really%20handy%20because%20it%20allows%20the%20records%20of%20a%20related%20table%20on%20the%20many%20side%20to%20be%20shown%20embedded%20in%20a%20so-called%20subdatasheet%20in%20the%20one-side%20table.%26nbsp%3B%20You%20can%20define%20it%20here.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3E%3CSPAN%20class%3D%22lia-inline-image-display-wrapper%20lia-image-align-inline%22%20image-alt%3D%22subdatasheetauto.jpg%22%20style%3D%22width%3A%20999px%3B%22%3E%3CIMG%20src%3D%22https%3A%2F%2Ftechcommunity.microsoft.com%2Ft5%2Fimage%2Fserverpage%2Fimage-id%2F261513iD675CFE61D2C6014%2Fimage-size%2Flarge%3Fv%3D1.0%26amp%3Bpx%3D999%22%20role%3D%22button%22%20title%3D%22subdatasheetauto.jpg%22%20alt%3D%22subdatasheetauto.jpg%22%20%2F%3E%3C%2FSPAN%3E%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EThat%20allows%20you%20to%20drag%20EVERY%20SINGLE%20RECORD%20from%20the%20many-side%20table%20into%20the%20one-side%20table%20when%20you%20open%20it%20in%20datasheet%20view.%20Seems%20handy%2C%20right%3F%20It's%20a%20drain%20on%20performance.%20And%20it%20is%20extremely%20unlikely%20that%20you%20will%20ever%20show%20the%20table%20directly%20to%20a%20user%20anyway%2C%20so%20it's%20sort%20of%20a%20superfluous%20fillip%20anyway.%3C%2FP%3E%3CP%3EFor%20that%20reason%2C%20most%20experienced%20Access%20developers%20will%20take%20steps%20to%20eliminate%20them%20as%20quickly%20as%20possible%20when%20they%20encounter%20them.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3EFor%20interface%20functions%2C%20rely%20on%20the%20forms%20that%20are%20the%20interface%20display%20tools%20in%20Access.%20If%20you%20need%20to%20see%20the%20two%20sets%20of%20records%2C%20rather%20I%20should%20say%20if%20you%20want%20to%20show%20the%20two%20sets%20of%20records%20to%20a%20user%2C%20you'll%20want%20to%20employ%20a%20main%20form%2Fsub%20form%20design.%26nbsp%3B%3CBR%20%2F%3E%3CBR%20%2F%3E%3C%2FP%3E%3CP%3EIn%20my%20more%20than%20twenty-five%20year%20career%20I%20think%20I've%20seen%20one%20relational%20database%20application%20that%20employed%20this%20feature%20in%20a%20production%20environment.%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Visitor

Hi Everyone, 

 

I am creating a client database using access. I have a main table "Contacts" which includes my clients and their information. I also have two other tables: criteria A and criteria B. The two tables have different column titles. In my Contacts table, the primary key is the contact ID. There is also contact ID in both criteria A and criteria B tables. I linked them as a one-to-many relationship (each contact can have several rows of criteria A and criteria B). As a result, in my Contacts table, when I click the little "+" button on the left side of each row, I can see the criteria A table bounded to the contact name. However, I cannot see the criteria B table anywhere. Vice versa, I would only see the criteria B table under each contact. 

 

Please let me know how to fix this and if there is a better way to plan this. Thanks so much!

1 Reply
best response confirmed by EricTao (Occasional Visitor)
Solution

@EricTao 

 

What you are describing is actually NOT a really helpful design feature, as a matter of fact. I'll get back to this point after explaining what it is. This is what is referred to as "Subdatasheet". It's a feature of Access which APPEARS to be really handy because it allows the records of a related table on the many side to be shown embedded in a so-called subdatasheet in the one-side table.  You can define it here.

 

subdatasheetauto.jpg

 

That allows you to drag EVERY SINGLE RECORD from the many-side table into the one-side table when you open it in datasheet view. Seems handy, right? It's a drain on performance. And it is extremely unlikely that you will ever show the table directly to a user anyway, so it's sort of a superfluous fillip anyway.

For that reason, most experienced Access developers will take steps to eliminate them as quickly as possible when they encounter them.

 

For interface functions, rely on the forms that are the interface display tools in Access. If you need to see the two sets of records, rather I should say if you want to show the two sets of records to a user, you'll want to employ a main form/sub form design. In this case, youll need two subforms, one for each of the Criteria tables.

In my more than twenty-five year career I think I've seen one relational database application that employed this feature in a production environment.