It's hard to tell, but it sounds like there are a couple fundamental changes you can make. You should move to having another table. Instead of a script with 200 If/Else If options, create a table with 200 records. On field would be the code, another field would be the reference. Then you build a relationship between the two tables and use an auto-enter calculation to set Field B. It's not entirely clear if Field A contains a single 7 digit number or a series of them (up to 25?). If a series, you should split those up into separate records as well. Also, are you getting 80 Million new records frequently or is this a one time process? You might be able to save a lot of time by using relationships rather than scripts, but 80 million records is a lot to update. In short, this isn't a scripting problem as much as it is a data structure problem. It would be helpful as well to have the actual data rather than samples. It is easier to understand. A sample file would be great.
Yes, well the Commit is a problem. Once you commit, that portal row now longer has focus so the rest of the script doesn't "know" that's the row you want. You could do the find. That's my general preference over GTRR. But you could simply take the Commit out. If you've edited the record (parent or child) and GTRR with a New Window that might record locking issues.
Add fields that can capture the unstored data in a stored format. Or just use $variables. You'll have your script do PSOS to grab all the calc results and pass that on to the client. Then go to your report layout, do your find and sort, but don't display your performance-killing unstored fields. Instead use the result from the script to populate display globals or variables.
Bruce, I'm confident what I said in my first post is accurate but I should clarify, the found set of the TO of the *current layout* stays the same when opening a new window. However all layouts based on other TOs revert. Keep in mind, in terms of maintaining found sets, FileMaker doesn't actually care about the layout, but rather the TO (not base table) of the layout. Here's a 1 minute video of what I'm talking about: https://youtu.be/fES-BcJCizE Steve's experience is a direct result of this behavior.
"Takes a found set and transfers it to the first table". What script steps are you using for this action? Regardless, found sets are tied to TOs and windows. Imagine all your layouts have a default found set (I'm not sure if that's all records, but I suspect it's the found set of that layout's TO when you last closed the file locally). So two layouts based on the same TO in the same window will have the same found set. Opening a new window means all the layouts in that window revert back to the original defaults. Manipulating found sets and switching between layouts in that window will keep those sets but won't effect other windows or layouts based on other TOs (even if they're the same base table) I hope that's clear enough.
There are other, better ways to sum subgroups of records aside from multiple relationships. If this is for display only, filtered portals and summary fields work very well if the number of total related records isn't large (more than a few hundred).
You've got to script the "quickfind". Popovers are just layout objects that help you manage your layout real estate. They don't have a separate table "context". I'm assuming you have a portal on the popover and *that's* the table you want to search? There's not a simple answer. And your "quickfind" field is a global of some sort? You can 1) Script it so upon exiting the "quickfind field" you can either create a bunch of find requests each with a different "related field" getting the quickfind data 2) Script it so upon exiting the quickfind field, you go to a different table (one the portal is based on), do a Quickfind search there and the Go To related Record back to the original table 3) Set up layout so only the related fields are set to "quickfind" 4) Rethink how to accomplish your goal. Do you need a popover? How about a new window to a layout based on what is your current "portal" table?
It's not an uncommon error. Go to Related Record will take you to *all* the related records for the current record. The checkbox option expands this to taking you to *all* the related records for *all* the records. Personally, I think GTRR is more trouble than it's worth. If you want to isolate a single related record, your best choice is to pass the unique primary ID of that related record as a parameter through the button. Then take that parameter (using Get ( ScriptParameter ) ) and do a find on your certificate layout to isolate the record. Also, your screenshots are a little confusing. Shouldn't the Certificate layout referenced in your "Email certificate" be based on Join Contacts Events table?
Do you have more than one tab control on the layout? There can be many "frontmost" tabs. FileMaker can't know which tab a user is actually looking at! A custom function like this is probably a better choice: https://www.briandunning.com/cf/694
You could make the portal as big as the longest invoice, put the text at the bottom and set the portal to "slide up". But you really should based the print layout on the line items table, not the invoice table so you're printing a bunch of records instead of one. Put your invoice-related information in the header or footer.
I won't do a demo, but I'll offer a couple more pieces. Create a table, Spec Index. Each record has a field for Job Type (or Job Type ID) and Specification. This will be a table you fill out once and rarely update. It will follow the same logic as your 41 hidden field calculation. Create another table, Job Specification Join. This table will have several records (one for each actual specification) for each Job. Write a script. When you create a Job and set it's "type", the script finds on the Spec Index for that type and finds the, say 5 Spec Index records for that Type, then goes to Job Spec Join and creates 5 records, setting the Job ID and the Specification. Now you'll have a Job record with 5 related specification records.
Snozzles, You should probably start a new thread for this. It looks like unusual behavior. Do you have other windows open? Do you have an OnModeExit script? You can get this dialog if portals are sorting, but that shouldn't happen in Find Mode. Are you sure you're in find mode when this dialog pops up? LaRetta, I must have missed the continuation of this thread somehow...I would certainly add that a script running in the script debugger does not 100% match the performance of that script without the debugger. Freeze Window is definitely one issue (it doesn't actually work in the debugger) but also Pause/Resume, and some other steps I've bumped into over the years. I'm not sure of a better test to see if local data is loaded when Freeze Window is followed by a layout switch, except using Wireshark or eyeballing the layout load speed for a table with big records. *I posted this as two replies, but the forum combined them...is that expected behavior?
First you need to grab the content of the web viewer. Use GetLayoutObjectAttribute() for that. You'll also want to check that the page has finished loading by ensuring the </html> tag is present. Then you'll want to find the position of both the onload=" string the the subsequent close brackets. There are several functions that you'll probably want to use: Let(), PatternCount(), Position(), and Middle().