I'm sure it's an easy fix BUT.... I'm wanting to set a field primary field from form A, then go to form B and see only the records that match form A. I keep going in circles. Please help.
Yes, there is a simple way to do it. We can do it by temporarily storing the record ID in a variable.
1. First we'll get the primary key from the record in Table A and store it in a variable:
Set Variable [ $RecordID_A ; Value: TableA::Record_PK]
Note this takes the Record ID from whatever Table A record you are on at the time you click the script button. If you're on Record 1024, then FMP will take the number 1024 and store it in variable $RecordID_A.
2. Then we'll open a new window for Table B:
New Window (set the type, size, which layout, etc.)
3. Then we'll search for the records in Table B that have the foreign key that matches the primary key of our chosen record in Table A. We enter find mode, then insert the record ID from Table A using the variable above:
Enter Find Mode [ Pause Off ]
Set Field [ Table B::TableA_FK ; $RecordID_A ]
So in English this opens a new window for Table B, opens a layout, then enters find mode, moves to the field that contains the foreign keys for Table A, and then inserts the number 1024, and hits the Find command. FMP then searches for all the records in Table B that have 1024 in the foreign key field.
Note the new window can open a list layout if that's what you want.
You might be thinking...hmmm...this is a lot like defining a relationship between tables. You'd be right. In fact, using this technique and the new FMP16 card window, we can use code to simulate a relationship even when the relationship graph doesn't define a relationship.
I'm sure it's an easy fix BUT.
Nope. Not an easy fix when tell us absolutely nothing.
Please provide more detail, and use meaningful descriptive language, not A and B.
A screen shot of your relationship graph would help; as well as names, table occurrences, and purpose of the layouts.
After that; yes; it's probably quite simple.
This has already been marked as answered, but you may want to look at the Go To Related Records script step as it accomplishes something very similar (and depending on how your relationships are set up, it can be done without any scripting)
You might be thinking...hmmm...this is a lot like defining a relationship between tables.
And of course; your suggested solution REQUIRES that this relationship has already been defined.
But then - that's an important, prerequisite detail that has not been described to us yet.
Bruce & Philip,
I've found that it's not actually necessary to have a relationship defined to use this technique. Of course it may be easier in many cases to set up a relationship and use the Go To Related Records script step. After all, the original poster (JammieSchmunk) could have gotten the output in the form of a portal with the related records.
I've been intrigued with the possibilities for scripting using this technique. It seems to save table occurrences in the right situation. For example, if I have places where I want to have related contacts on a layout I can do that with a relationship and a portal. That's pretty easy -- put a new TO on the relationship graph and create a portal.
But the hassle starts when I want to go from the person's name in the portal to the detail form for that Contact. Please tell me if I'm missing something here. Let's say I have three contexts from which I would need to go from a portal for related Contacts and the Contacts detail layout. If I'm getting the Contacts detail from different contexts, e.g. Project_CONTACT, Invoice_CONTACT, Meeting_CONTACTS, then I need three Contacts detail layouts, one for each context. The layout are the same except for specifying which TO the data comes from, which is specified for every field. I end up with three layouts that are identical except for the TO references. This creates some busy work. If I want to modify my Contacts detail layout then I have to edit three layouts. The same applies if I am using popovers from the portals; I would have to create and maintain three popovers.
I have found that rather than using the GTRR script step, I can use the method I described above and have one Contact detail layout and none of these TOs. I can call that one layout from any portal by simply grabbing the Contact ID from the portal row and use it in the script I outlined above. FMP opens a window and does a Find that returns one record. I can even use a card window that looks like a popover. It seems that this will save some time.
The same technique could be used for data entry, say, if I'm on a Project layout and I want to enter a new Contact. The script copies the Project_ID to a variable, opens my (one) data-entry layout and inserts that Project_ID into the foreign key field, and then I hand-enter the person's info.
I see that the advantages are that this technique eliminates relationships and extra TOs (especially the single-purpose little utility TOs). It makes layout management easier. I haven't seen a downside, except that rather than a simple GTRR step the script is longer.
Does this make sense?
An often missed detail is that when you specify the layout for GTRR, it needs to have the same base table as the "table" (TO) specified but it does NOT have to have the same exact TO specified. So in your case, you do not need multiple identical layouts that simply happen to be based on different TO's. Once can be used from mutliple GTRRs that use different relationships but which link to a TO of the same Base table.
Phil, thanks for that.
You're right. I did a little experimentation. If there is a relationship then the detail layout will pull the field data. E.g., a Project layout with a Contacts portal. But it appears there is an except if it goes another step, e.g., a Project layout with a Contacts portal that opens a Contacts detail layout that has a portal of related Meetings. FMP will pull the Contacts table data but won't pull the Meetings table data unless there is a TO for Meetings connected to the Contact TO. If I have a Contacts portal branching from other Base Tables then for each base table I would need to make a Contacts --> Meetings TO pair and need an additional Contacts layout for it.
I can think of another exception to what you wrote (another use for the technique). This appears to be similar to the use case for the original post of this thread. Let's think of the vanilla situation where the relationship is one step, such as Project --> Contacts. Usually there will be a Contacts TO because we want to create a Contacts portal on a Project layout. However, there might be cases in which we don't use a portal such as when the information is needed rarely. I could put a Contacts button on the Project layout and use the technique to open a Card window list of all related Contacts, and do it without a TO relationship. The button would be portable to any Projects layout or Projects portal, without a Contacts TO, and without modifying the script or Contacts detail layout.
Thanks for making me think this through.
I don't see any "exceptions" to what you have just posted. You've simply documented how layouts and card windows function.
I was stating that you didn't need identical layouts with different TO's specified as their context. If you put a portal on one layout and not on another, then you no longer have identical layouts.The GTRR will pull up exactly the same found set on any layout with a TO based on the correct base table, but once you've pulled up that found set on that layout, then the layout's TO will control what access is possible to other records related to the records of that found set--such as the presence of a portal on the layout. The same would be true if you performed the same find on the two different layouts.
And you don't need a portal for GTRR, just the relationship. Your description of using a card window is a perfectly good way to to use GTRR, but that card window needs to specify a layout with a TO that has the correct base table--as would be the case for any new window you choose to open with the GTRR script step.
Please note that I am neither arguing in favor of GTRR nor against performing a find. I use both all the time and choose the method most effective in light of all the requirements of that part of my solution design.
Retrieving data ...