Start with these relationships:
Hikers::__pkHikerID = Hiker_Trail::_fkHikerID
Trails::__pkTrailID = Hiker_Trail::_fkTrailID
You can place a portal to Hiker_Trail on the Hikers layout to list and select a Trails record for each given Hikers record. Fields from Trails can be included in the Portal to show additional info about each selected Trails record and the _fkTrailID field can be set up with a value list for selecting Trails records by their ID field.
For an explanation of the notation that I am using, see the first post of: Common Forum Relationship and Field Notations Explained
This is just one possible example, it links individual hikers to trails. If you are managing groups of hikers, you may need to modify this design if you want to see data for either an individual hiker or the group that they hiked with on that given day.
I've set up those relationships, and it will populate the fields (though I can't figure out why it won't make it a scrollable list even though I check that - different topic). I guess I should have been more specific. I don't want the user to be able to modify the two fields, just select the HikeID and have those two fields populated. Maybe it's not a "portal" that I want, but I'd like a scrollable list to see all the hikes a user has taken. Maybe that's my answer - don't use a portal? But I don't know how to add a line to the scrollable list, as a portal allows (but ads a new record also). As I say this, I actually would like a way, from the user layout, to ADD to the list of hikes. For example, if the user creates a new hike, be able to give it a hike name and description. That may be another whole topic in itself too. I guess what I'm looking for first is a simple way to populate a layout with values from other tables, where those values are not editable from the current layout.
You should use a portal. As specified in my last post (which may or may not be exactly what you need), you create a series of record in the Hiker_Trail table, You select from a drop down list to select the trail record you want to link to the current hiker record.
So if you are in Yosemite, you might select the Vernal falls trail for your first hiker_Trail record and select the Bridal Veil Fall trail for a different record. Once you have selected a trail, any fields from the Trails table that you choose to include in the portal row (say the length of the trail or such) will automtically display data about the selected trail.
Thanks Phil. I spent a long time today getting this to work in the portal. Getting the exact right fields displayed to select was not working until I finally figured it out, then it made sense. Apprecaite your help.
Now to make your life a bit more complicated. This is one of two "look up" methods you can set up for this type of data entry task. Each method is the best approach in different circumstances. The method we have discussed here uses a live or "dynamic" link to the data in the related table. If you go to records in the Trails table and update some data in it. Any Hiker_Trail records that link to it will automatically update to show the updated information. If that data is the length of the trail or other physical characteristics of that trail, that's probably what you want.
But if you need to capture a value from the related table that is the current value at the time the record is created but you don't want it to change in the future even if the value in the related record changes, you need to use a different method. An example is when you have a list of prices in an invoicing solution. You want the system to look up the prices that are in effect at the time the invoice is created, but you don't want the prices in past invoices to change when you change a price.
If this turns out to be what you need, then a looked up value auto-enter field option or an auto-enter calculation should be used to copy the data from the related table into a field in the join table. An example in your case would be if there were a field in Trails that documented the current fire danger. Since that rating will change over time, you might want to copy that data via an auto-enter option instead of just adding the field from the related table.
Yes Phil, just what I need, more complications!! :-) Truly, thanks for this information. At this point, I don't think I need that latter case, but I'll be sure to keep your email around in case I do for some other scenario. Just a quick question, when you say "...copy the data from the related table into a field in the join table", I assume you mean (in my example), the Hiker_Trails table, (the table that pretty much just links Person and Trails) right?