I have a file that shows the issue and would provide this one.
2 Likes
Claris informed that spinballing at each attempt to scroll is expected behaviour…
Server and Client are in the same room on GB Ethernet. It cannot take a minute to load another 10 records. Up to 10GB of ram taken but not all records are loaded, spinballing for loading during scroll. The entire file is 1.9 GB! No need to examine the incriminated file.
Case closed 
Nailed it!
I could track it down to a script that retrieves node (record) IDs and writes them to number fields. The table actually holds a xpath list.
The script sets parent node IDs for all path levels of an item i.e. L1_Parent…L15_Parent.
In order to avoid a long if - else if sequence I used the convenient ‘Set Field By Name’ step, calculating the field name. A file is ok until the first run of the script, which balloons the file size 10-fold and cranks up ram consumption. When the script finished, I get spinballing instead of scrolling. Taking a fresh file, I replaced the step by a ‘Set Field’ step - no problem at all. Obviously, FMPA can’t stomach the ‘Set Field By Name’ step here. I have no explanation for this.
3 Likes
strange. I’m using ‘set field by name’ quite a lot, starting with filemaker 11. We did have some issues in some spots ever and ever again - but not in this context
found the thread on fmi forums this morning - and I’m not sure if Mr. Kurasch got the issue
- loading records in a local system with gigabit ethernet should not beachball, if there is no ‘endless loop’ (‘Schwanzbeisser’ in German, an animal that bites it’s own tail)…
2 Likes
It is super fast, the problem is with the ‘Set Field By Name’, which I use here and there and never caused an issue before. That was a tricky one to find out.
Well, Claris has already ended the investigation. If FM eating up 10GB of ram for hosting a file one fifth of that size does not trigger curiosity, I can’t help.
1 Like
and I’m not sure if Mr. Kurasch got the issue
I think I know what you mean:
https://community.filemaker.com/en/0D70H000005ccFb?fromEmail=1&s1oid=00Di0000000eyqY&s1nid=0DB0H000000fxYs&s1uid=0050H00000Bq5vP&s1ext=0&emkind=chatterCommentNotification&emtm=1570139251176
1 Like
well… we have had critical issues with one iPad/FMGo Application where we lost data. Filemaker said that it was due to our own development…
After the third patch of that particular version, that very same issue disappeared
That is one reason that I’m asking for detailed info about release notes
2 Likes
@jormond, thanks for the hint. Starting from a clean file was actually part of my hunting strategy. The observed issue is 100% reproducible, as is the workaround.
I have to correct myself. The issue appears with both ‘Set Field’ and ‘Set Field by Name’. It was a reduction I applied in my test set that made it look like having gone, my bad. With the full set of fields filled in the script loop, it is still there.
Later this evening, I will prepare a demo file and load it up here.
2 Likes
Just curious about the Freeze Window option. Not an option anymore?
Thanks for clearance and validation. Maybe should update other thread Should we, just because we can?
where Set Field by Name under suspicion…
Mystery solved for good! It is a perfect showcase for the necessity of @AndyHibbs’ ‘Should we just because we can?’ thread.
I could finally track it down to being a data type issue:
The script takes record IDs (number field) and sets for all records the parent IDs for alle path levels applying to a record (Lx_Parent, number fields) . The script keeps a parent ID stack from which the IDs are retrieved and copied to Lx_Parent fields.
FMPA takes IDs (number) from ID fields, stores them as a VL in a variable, from where they are picked and copied into Lx_Parent fields (number). No hurt points spotted so far.
However, despite the ID values copied to Lx_Parent fields have been generated by FMPA itself (ID field), it struggles putting the back as a number in a number field. Without explicit type conversion back to number format (GetAsNumber()), the file bloats from 6 MB to 829 MB, memory use goes uptimes to 8 - 10 GB and the each action (scrolling, opening script editor, closing file) produces a minutes-long spinballing.
Clearing all Lx_Parent fields in all records brings the file back to its original 6 MB size and normal behaviour and usability.
Running the same script with explicit type conversion, size goes to to 8 MB and all remains normal, no spinballing. Conclusion: FMPA does not convert a string that consists exclusively of characters ‘0123456789’ to number format when copying that string to a number field. For a reason I do not understand, this leads to severe problems with the file.
Attached is a sample file. User: admin, no pw.
FMPA Type Conversion Isssue.fmp12.zip (522.3 KB)
3 Likes
That is an interesting conclusion. Definitely send this in if you haven’t already. There are definitely times that the data type gets changed. Setting to/from variables is sometimes one of those times, but not always.
Interestingly, doing any math ( like adding ‘+ 0’ ) also forces it to a number data type.
Good detective work.
1 Like
Thanks, @jormond. Got useful hints from you and others.
I posted an issue report in Claris’ forum and offered a sample file. The offer was turned down. According to Claris, the spinballing, memory and file size bloating I reported is expected behaviour. The case is closed over there.
2 Likes
Post the file anyway. I’ll reach out back-channel to ask that they look at the problem.
Explain what you found, so they can see it in your own words.
3 Likes
Claris’ attitude left me speechless. I’m done. Please feel free to take the file and follow up with them.
P.S. All relevant information is available here for everyone who is interested in the case.
2 Likes
Torsten, I’ve just run this on my Catalina 2018 MacBook Air. I’ve expanded your zip file each time and run the non explicit script each time to double check the results.
I was going to report that I’m only seeing the 834Mb (in my case) and spinning beach ball using FMPA 18.0.3, not FMPA 17.0.7, but then spotted the While in the Decrease_LIFO_Stack custom function, which also explained the question marks in L1_Parent field throughout in v17 and probably why there was no size increase.
The resulting file after the non explicit script run is unusable, just clicking on any field, or menu results in the spinning ball without any scrolling, so if it is standard behaviour, then rendering a file useless using these standard features must be standard behaviour.
Just wondered whether it would be worth replacing the While in the custom function with a recursive custom function and rerun the process on both versions?
My wife/co-director/co-developer is twisting my arm to drive me to a local pub for a pint of real ale, so this will give us something to talk about there.
2 Likes
it’s a shame! This matches my experience with bug reporting too.