Can you show a screenshot of your script? What happens when you run it through the Script Debugger with the Data Viewer open (if you have Advanced)? Other thoughts"
1. Why are you flushing the cache?
2. I think you would have to commit the record in the first layout before you went to the related record layout, that's why you are getting the error message. The order should probably be....commit record, then go to related record. Are you sure when you go to related record you have selected the correct layout, checked 'Show in New Window' & "Match Current record only". Match current record will take you to the proper related record but will still have a found set of all related records.
Thank yo u Steve. I don't have advanced. I doubt I'm more than moderate beginner.
1. I'm flushing the cache as this was a script copied elsewhere in the forum for this issue, removing this step from the script doesn't appear to alter its performance.
2. I have quadruple checked that the "show in new window" & "match current record only" have been checked. Hence my puzzlement when I tried b and found it takes me to the first related record rather than the current record.
The error message is what's really getting me. I saw in the forum a post from about 2011 where you had to click outside the portal to commit. Seems we are back there because I cannot get the script to do it.
I may have to post screen shots in the morning. It's midnight here in Australia
I can see one problem in your initial post if your button is located inside the portal and the script is intended to bring up that related record on another layout.
Commit records will "lose" the "focus" on the specific row clicked. GTRR will then execute as though you are clicking the first portal row each time.
You may need to post the actual script (the details matter) so we can see what you want it to do and where it may be failing.
To post a script to the forum:
- You can upload a screen shot of your script by using the Upload an Image controls located just below Post A Answer.
- You can print a script to a PDF, open the PDF and then select and copy the script as text from the opened PDF to your clipboard for pasting here. (with this approach, you can get multiple script steps on the same line, please edit the pasted text by inserting some returns to separate those steps.)
- If You have FileMaker Advanced, you can generate a database design report and copy the script as text from there.
- If you paste a text form of the script, you can use the Script Pretty box in the Known Bugs List database to paste a version that is single spaced and indented for a more professional and easier to read format.
Here is the script that is failing to commit (based on a relationship Customer---<Vineyards). A similar script is used for going to patches from the vineyard based on a relationship Vineyard---<Patches, and also fails to work, but I haven't included it as it's exactly the same.
Vineyard scripts: Go to Related vineyard
[ Flush cached join results ]
Go to Related Record [ From table: “Vineyard”; Using layout: “Vineyard” (Vineyard) ] [ Show only related records; New window ]
It is based on one which works and which I've reproduced below and which does commit. This is based on the relationship Blends-----<Operations.
Wine scripts: Make operations note active
[ Flush cached join results ]
Go to Related Record [ From table: “Simple Operations master”; Using layout: “Simple Operations master” (Simple Operations master) ] [ Show only related records; New window ]
I have also attached a PNG of my relationships. While I'm pretty certain that they are OK I can always do with another pair of eyes.
Many thanks Steve and Phil.
Refresh WIndow [flush cached join results] should be avoided if there is any possible way to do so. It can result in major delays while your layout updates--especially if you have large numbers of records being referenced, a slow network (such as a WAN) or an iOS client (iPad, iPhone...).
What problem does that Refresh WIndow step solve for you? What happens if you a) remove the "flush" option or b) remove the step altogether?
Looks to me like the record has to be committed by your script, but that doesn't mean that something else isn't re-opening that record for editing after it is committed. Might there be an OnRecordLoad trigger set on the original layout? IF there is such a script and it has a go to object or go to field step that puts the cursor into a field in the layout, this will open a record for editing and that can result in the error message you are reporting.
I've been quiet and quietly going bananas over this.
- checked every script, button and trigger including layouts to find the reason why the original layout retains focus, instead of making the new window active.
- removed the refresh/flush cache step from the scripts
- tried putting the script into button setup (i.e. run script on button setup instead of go to related record), with no script triggers for the button
- tried removing all scripts with a straight GTRR command on button setup
- changed to "no action" on button click, but set the script trigger for the script
- created a completely new set of forms with portals
There's obviously something I'm missing. So far the only way I can get the record to commit so that the button takes you to the related record and allows you to edit the related record is to click outside the portal before clicking the button. Is there a command that will make the new window active on open?
Thank you in advance
If you had Advanced, you would be able to open the Script Debugger and see exactly what is, and isn't working. Second option might be to post a clone of your database up on dropbox, with a link here, and let others take a look at your DB and scripts.
Clicking outside of the portal is the same as a script performing the commit Records script step. But that also loses the focus on your portal row. Consider this script:
Set Variable [$Row ; value: Get ( ActivePortalRowNumber ) ]
Go to object ["objectNameassignedToPortalInInspectorHere"]
Go to Portal Row [$Row ; No dialog ]
#put rest of your script here
This is the scripted equivalent of clicking outside the portal and then clicking the button to perform the script.
Thanks Steve - very much appreciated. My database at the moment is full of junk as I try and get it working. I will clean it up before uploading as suggested. This may take a few days as I have to go off-line for a bit.
I have the same setup as Jenny. If you enter data into the bottom portal row, the record isn't committed by tabbing to another black row. So this script seemed like the solution. However, I also sort the portal rows by one of the fields and, once the commit command is run in the script, the portal rows sort themselves and the $Row variable isn't the row that the new record is in after the sort so the script fails.
My questions is there any other way to locate the new record besides using the portal row number?