Having problems with script Get(FoundCount)

1

I have a scripting issue using Get(FoundCount), where nothing is being saved to the global fields I defined (both as global, number).

I have a music database which contains album information (in the primary table), and a second table which contains tracks information for each album. The link between the two tables is an album ID. The issue with the Get(FoundCount) arises in a script which genertes reports for the libraries within the albums table. In the report headers I want to print the number of found items in the album table and also the number of found records in the tracks table.

The script is set up to find the appropriate (pop, classic, or keyboard) records from the album table, sort the table, then save the found count in the global field I defined in the album table.

Then a second find selects the appropriate records from the tracks table — which is the total number of tracks for the selected albums found in the first find. Then there is a script step to save that found count to a second global field.

Upon conclusion of the script, both global fields are empty.

I am doing something wrong or illogical, as this seemingly straight-forward logic isn’t working.

The concept of focus was mentioned in various answers on the web, so I thought perhaps it was necessary to include a ‘Go To Layout’ script step just before each Find and Set statement. This made no difference in the results.

I am just about ready to give up on this “finishing touch” to the reports, perhaps by manually performing the ‘finds’ and plugging those figures in directly to the global fields so they will print in the report header.

Any suggestions as to what I’m doing wrong?

2

In reports, you get the totals using summary fields ( Count of).

That’s where FileMaker really shows its strengths.

Jan

1 Like
3

Is this script running locally on your (client) machine?

If so, I would suggest making sure that the advanced developer tools are available, and using those tools (in particular Script Debugger and Data Viewer) to step through the execution of the script so that you can watch firsthand to see when and if the global field values are being modified.

Stepping through a script in this way is often a good eye-opener to help spot:

  • simple mistakes related to scripting/calculations
  • false assumptions about data or the runtime context

p.s. Welcome to the Soup!

1 Like
4

Thanks for your timely response. I had forgotten about the debugging tools and how useful they can be when results are not what I expect. I'm now using those tools to investigate a few other issues that I've spotted in these long-ago-designed databases.

I solved one problem I had with getting the found count, thanks to a reply I saw elsewhere about using the "insert other" symbol for FoundCount, which eliminated the need to store the count in a dedicated field: now I simply display/print the count in the report heading as a text constant.

5

I appreciate your quick reply.

I have used summary fields (Count of and Sum of) for other purposes, but had not thought of that to solve this problem. I will look into it. Thanls!

6

The simplest way may be to put an unstored calculation in the child table that does a get(foundcount). Then whenever you reference that field from the parent table layout, it reflects the count of the related records, based on the set of related data in the parent.

One of the few places where an unstored calculation makes sense.

You could also put a calculated field in the parent that counts the number of primary keys in the child table that is related. However, the unstored calculation approach in the prior paragraph is more efficient

7

I tried both solutions you suggested, and settled on the first one, since it worked and seemed the most direct and uncomplicated.

Thanks, George

8

Key point. UNSTORED calculation. It is infrequent to recommend an unstored calculation for performance reasons but in this particular case, it is the most performant approach.

9

it depends on what you do with unstored calculations.
There are lots of instances where they're useful. Everything environment-related (Get and design functions). In this instance, it avoids downloading records. Get ( FoundCount ), Get ( TotalRecordCount) , Get ( RecordID ) are especially useful for that.

2 Likes