Ok, a couple of questions/notes:
Why is there a "Restore" on the Perform Find step?
If you are entering Find mode, setting fields to search on...there is no need for you to specify the search in the Perform Find step. I'm not sure, but that conflict may be causing an issue as data is being sent back and forth to the server.
The Enter Browse Mode step is also unnecessary.
Also, how are your taskid values setup that you need to search with a wild card before and after the id?
Excellent advice. Thanks, but...
Locally: Find with no wildcard works correctly. Find with no restore, just using "Enter Find Mode" with set field, works correctly. Dropped enter browse mode.
Lineage is concatenated record list. A001-A005-A023-A046. Thus search for A005 finds all subordinated tasks for task A0005. Search for A023 finds all subtasks for A023. Makes possible very fast searches through deep tree. Worked fine in FMP 10 on remote server with both FileMaker client and web access. Several years ago,
With cleaned up and simplified script, same remote access error. Works properly locally. Instant crash on any remote access, FileMakerGo or FileMaker client, local remote or Internet. Same error as before, instant crash when script hits Perform Find. From using debugger with FMPA on remote client.
Copied script to a different online database. Worked perfectly remote and local.
Cleaned up and simplified script. Works perfectly locally. Crashes on remote access.
I have rebuilt database on new blank database using copy/paste from old database. Reinstalled FMPA 14.0.5, but not from scratch.
I was a heavy FMP developer FMP 7-11. Dropped out after FMP 12, so am returning, after extended absence, to FMP 14.
Verify that you have FMGO 14, FMGo 13 had a memory leak that caused crashes.
Close the database on the databases, Close FMGo, then power off your ios device. Power backup and retest.
You may have a corrupt object on your layout. When a fp7 file is converted to fmp12 it doesn't always goes as planned. I suggest rebuilding the layout without copying items from the current layout, the corruption can be copied. It would be wise to run recover on the file. If Recover finds anything then you would need to go to an older backup without any issue. I doubt Recover will find anything. You could also copy the current layout to a new layout and then start deleting items from the new layout to try to determine which object is causing the issue. Note there may be more than one corrupt object on the layout.
Thanks to you, solved it. Don’t know cause but have solution.
Search field was a concatenated calculation of local variable, Task ID, and related variable, Task Lineage. Field could not be stored nor indexed. So (apparently) not searchable remotely.
Wrote simple script that writes calculation result into static text field on record commit. Then searched "Task Lineage Static" instead of "Task Lineage Calc". Now works perfectly across all platforms.
No idea why remote search on calculated field resulted in instant crash of FileMaker Pro Advanced 14.0.5. Entirely possible that I migrated some sort of hidden structural error from fmp7 to fmp12 format.
Once again, your advice was what led me to be able to figure this out. So thank you for your time and consideration.
Very possible. I've seen a lot of crashes with Finds on Go. Not entirely sure if the cause yet.