I read your original post and it got me thinking about how I might solve this problem, thought I'd share. Much of this overlaps with Chad's comments:
- What you're describing is a many-to-many relationship, not a one-to-many. As you said, one FSR can have many calls, but one call can also have many FSRs.
- The way to properly handle a many-to-many relationship is to have a third cross-reference table which has the unique record keys from each of your two tables.
- Just in case this wasn't clear (it wasn't for me!), a GRID and a TABLE are two different things. A grid is a way to display data from a table on your screen. A table is where data is actually stored, as records with unique RecordIDs.
- Another Method fact: every table comes with a built in "RecordID" field, that acts as the unique key for that table. We like to add fields like "FSR #", "Call #", "Invoice #", etc, which are also supposed to be unique values; but unlike RecordIDs those fields are of your own creation, meaning you can change their values, opening the possibility of accidentally having two FSR's with the same #. RecordID values are unchangeable, adding a layer of security for database management.
Call your third "cross-reference" table whatever you want .There are only three fields that are vital for it to contain:
1) The table's RecordID (which comes prebuilt in the table, so you don't need to add it as a field),
2) the "FSR#" (or, better, the "FSRRecordID") field,
3) and the Call# (or, better, the "CallRecordID") field.
You can add more relevant fields if you like - the customer, for example. But since that data is probably already in your FSR or call table already, it's not necessary. Also, I believe you will be benefited further on if you add the FSR# and Call# as Linked Fields, meaning they will reference the values in the FSR and Call tables, instead of you having to copy those values over.
The tables records will look like this:
Record 1 | FSR # 1 | Call A | Customer X
Record 2 | FSR # 1 | Call B | Customer X
Record 3 | FSR # 2 | Call C | Customer Y
Record 4 | FSR # 3 | Call C | Customer Y
In these example records, you can see that Customer X made two calls that were handled with one FSR, while Customer Y had two FSRs that were in response to one Call.
So now you have this table, but how do you relate multiple calls to an FSR and vice versa? You've got options for how you handle it, like a dropdown right in the FSR and Call screens, or just a button that opens a popup screen based on the cross-reference table, or some combination of both. Here's a quick idea on how to do it
1) On your FSR screen, have a dropdown based off the Call# table, filtered by customer.
2) Add a button (either the dropdown button or a separate one if you want a nice label for it), whose action set inserts a new record into the cross-reference table which inserts the screens FSR# (or Record ID), and the Call# that you select from the dropdown.
3) Now you can stick a grid in your FSR screen based on the cross-reference table (you'll only be able to base it on this table if it is linked to your FSR table, hence my suggestion for using linked fields earlier). Have the grid filter to only show records that involve the FSR # that you have open on the screen, and for columns you'd really only need to add a "Call #" column (also maybe call date, or other call table data that you copy/link over to your cross-reference table).
4) Do pretty much the exact same thing for your Call screen.
With this setup, you should be able to link an FSR to a Call and vice versa mulitple times, using that dropdown. The grid you inserted will show the calls that you linked to the FSR right there on the screen.
There's plenty of customization I didn't mention that would clean this up. You can add a screen to allow editing of those relationships (eg deleting an FSR / Call relationship that you accidentally created). You can add useful features, like having those Call #'s on the grid in your FSR screen be selectable, so when you click them they'll take you straight to the call screen. There are probably additional filters, validation checks, etc that would be useful in this setup, but that will become clear with trial and error.
Hopefully you can get through this without going crosseyed. If any part wasn't clear let me know, I'd be happy to clarify. But if it made sense and you want to give it a shot, I'm also happy to offer specific advice on action sets related to this. Compared to the stuff I'm trying to do on my own account, this is downright pleasant!