When looping in a script over a large data set (38’000 records), FMPA goes off the rails and leaks memory.
The concerned layout (table mode) shows a calculated field (result type text, store calculated result).
The script does not alter the two fields used in calculation. No recursions involved.
Script structure:
Loop
#Do some stuff
Go To Next Record (Exit after last)
End Loop
Expected behaviour:
FMPA slower than without the calculated field on layout.
Observed behaviour:
FMPA slows down to a crawl and eats up most of the available memory (see screenshot). After ending of the script, FMPA became unresponsive at attempts of scrolling in layout and ate more memory. Required termination of FMPA and restart.
Taking the calculated field off the layout or adding a 0.1 sec Pause Script step before ‘Go To Next Record’ solved the issue.
The last time I reported a severe bug, it took over 2 years to get that fixed - and there was no workaround and no information provided if it will be fixed at all. For this one there are several workarounds. No hurry to wasting time on typing a bug report.
What a mess the forum change was and still is // it’s dead Jim!
Getting Bugs across is tedious and frustrating but it has to be done just for the sake of informing others to save time and confirm that there might be an issue with the product (and not with the developer).
// thanks for fighting for a better product and being upfront and honest.
More interestingly, I observed the following today:
open file in FMPA, layout ‘Import’, table view
selected row is #1
click ‘Records’ slider in toolbar to rightmost position (select record #38145)
FMPA starts spinballing for minutes and balloons to over 10GB ram, keeping over 9 GB ram when finally spinballing stops and selected record is shown at the bottom of the screen
try scrolling up from there, FMPA starts spinballing for a while, whait for that to stop…
click ‘Records’ slider to leftmost position (select record #1), wait until spinballing stops and record #1 is shown on top of list. FMPA down to 1 GB ram
scroll down from there, works just fine
This cycle can be repeated at leasure. I ran the file through recovery, no errors found.
File has text and number fields, no calc fields. 38145 records, 1.9 GB.
Curious if you see the same issue in form view? Clay has spoken often about looping in Form view vs list or table view. Not sure the impact with the bug you are describing, but curious.
Do the same for script runs. For development I need to see these tables and according to FM’s tech spec, this should not happen. Meanwhile, I emptied and re-imported data and re-run the subsequent script in order to exclude a foul index. Makes no difference.
Other observation:
with active record #1, ram usage is 0.9 GB, at record #20’000 ram use is 4.99 GB and at record 48’000 ram use is 8 GB. So this is fairly linear behaviour. When scrolling up from record 48’000 FM starts spinballing immediately, this becoming useless for viewing the table.
