I'd need to know your current design of the layout, the underlying relationships and the script that you are trying to use before I can make a specific suggestion. But what you describe might be a typical "master-slave" pair of portals. If so, this thread may help: Need layout solution for nested portals...
Thank you so much, I reviewed your writeup on "master-slave" made the necessary adjustments and it now works beautifully. I had sort of worked it out before your post came in but your solution is, by far, more elegant.
My next step is to be able to add/change/delete and scroll through the grandchild portal records. Since this layout is using the parent table, do I need to create another layout that uses the grandchild table to add/change/delete records and return to the parent layout or is there a way to accomplish this within the parent layout? Again, my thanks,
I can't think of any reason why you can't delete or edit records in the grandchild portal simply by interacting directly with the portal. Adding a new grandchild could be handled by using a button performed script that creates the new record with all the correct foreign key values so that it appears as a blank row in your grand child portal.
Hmm, I have setup scripts for add/change/delete and the icons are inside the grandchild portal however when I run the script, it tries to add/duplicate/delete the parent records, not the grandchild records. Script runs: (1) set variables (2) create/duplicate record (3)set fields (4) commit
I'm not quite sure how to tell it to look at the child table rather than the parent.
Please ignore post above, I named the portals and the sun shone through! Thanks for all your assistance, the whole thing works beautifully.
OK, I am stuck once more. I need to test if a new record request is made on the summary/child portal so that I can update key fields and actually create the record before going to the slave portal, however something is not quite right. I know I have to set some sort of script trigger on the master portal, but how? I've tried a few things and spent hours trying find a similar issue on the forum but to no avail. Any assistance would be greatly appreciated, thanks so much,
I don't see why you need so many scripts. Just changing a record in the portal can be done directly without using a script. Only if you need to add or delete a portal record would you need such a script. You can see an example of a delete portal row script that I prefer to use in the Known Bugs List Database. This script is fully portable. It will import error free into any FileMaker file of the same file extension. The key info specific to a particular portal is passed in a script parameter to the file so you can use the same script and even the same button that performs this script in every portal in your database file where you permit deletion of portal rows.
And adding or duplicating a portal row record is not something that I would do by using a script to interact with a portal on the layout. I'd use Go to Related records to bring up these records on the portal's table and manipulate them there by duplicating an existing record or just adding a new record. And you don't even need Go To Related Records to add a new blank record to a portal:
Set Variable [$PrimaryKey ; Value: ParentTable::PrimaryKey ]
Go to Layout ["PortalTable" (PortalTable) ]
Set Field [PortalTable::ForeignKey ; $PrimaryKey ]
Go to Layout [Original Layout]
This has to become a bit more complex when working with a grand child portal , you might need to capture a value from your global field that controls which set of records are in the grand child portal, but the principle is the same.
Sorry Phil, I wasn't very clear on what I am trying to do so have included a screen shot to try and explain further for I truly appreciate the time you are giving me on this.
The parent record is the actual product; there is no issue handling record management here for the layout is linked to the Parent table - and the information presented from the parent table is for information only purposes in this layout (Collection Reference Details). What I am having difficulty doing is adding records to the REFERENCE table which are displayed and handled through the child/grandchild portals. The trouble is I have to add both a primary key from the parent record as well as a match key that identifies type (i.e.: comparison, note, document, citation etc). If a user clicks on the child portal that is located at the bottom of the screen (this has been set to add records in relationships), they see an empty grandchild portal above to begin adding details (this does not have the option to add records otherwise I get an extra row showing up).
However, the match field does not transfer to the grandchild portal (I usually set this through a script parameter) and the only way I can think to do this is to somehow test when an "add record" is selected and actually create the record before it hits the grandchild portal. I thought if I use a script trigger attached to the child portal, I can create the record and present it above with primary and match key requirements intact but how? I originally set the script trigger to the child portal itself but the child portal is holding onto the last record read so my test for a blank match field does not work. I then tried the child portal line but of course that does not work. So, this is why I am stuck. I know there has to be a way to do this but I have only been working with FMP for few months so am not sufficiently versed in the product to know all the calls and tricks. Do you have any ideas?
Once more, thank you for your assistance with this,
The method I described in my last post can be set up to do this. You just have two values to put in variables and to set to fields with set field instead of just the one Primary Key.
A button in the Child Portal row should work to create a new blank record in the "Grandchild" portal area shown on your layout by entering the correct values in both of the fields needed for this to work.
But I will also observe that I don't see any grand child portal here. I only see a collection of fields from a single grand child record. That suggests that you may have a single row portal here that is not visible in browse mode and thus I can't see it.
Exactly how have you set this up? What match fields, relationships and portal filter (if any) have you set up? With that info, I can be more specific.