Try changing into find mode before going to the Job layout. This will stop FMP from trying to bring data down from the server to display the current record (or current found set in list view) while in browse mode.
I tried it and found no change in behavior.
What I find really strange is that the app hang happens before it even gets to the first script step. While the debugger is open, the script steps never even display. There's no chance to even step over the `Enter Find Mode` or `Go to Layout` script steps. It seems to have a problem just loading the script for execution. I've never seen this, but this may be the first time I'm scripting a find across a shadow table into a relationship in a local table. At this point, I'm working around it with other techniques, but I'm wondering if this is a known problem, or if something else about what I'm doing here might be.
A hanging FMP is not necessarily a crashed FMP.
If I may explain. FMP may become non-responsive because the ODBC driver is attempting to retrieve data. If FMP is trying to retrieve a large amount of ODBC data it may take a vey long time. That isn't a crash. Eventually it will probably respond. Looking at processor usage may show some minimal usage giving an indication that FMP isn't crashed.
Our problem is not knowing if the processor is churning away with the ODBC driver and not allow FMP any access or if FMP is doing stuff but it can never finish it.
If you were to wait a few minutes/hours/days FMP might actually continue. So that's just a very long response time.
Look at the TOG for the FMP <-> ESS relationship. I think you'll see the connector show as --| on the ESS side. That indicates the ESS side is treated as an un-indexable field. If your using the ESS TO as a join table between for two FMP files it won't work and will cause the FMP requests to the ODBC driver to be undefinable. The gathering data process in FMP may be getting every record of the ESS for every record of the FMP table and then trying to get every record of the second FMP table for every record of the ESS table. Ugh, that's even hard to say let alone wrap my head around it.
If the relational model results in this kind of recycling retrieval of the data it may be getting the same sets of data over and over. That is not a crash either (FMP or the ODBC driver is very busy). However it is an unrecoverable circular reference. If you can check the ODBC data source log for the FMP ODBC requests then that might also help indicate what is going on.
I've seen ESS tables that cause FMP to become non-responsive. I recommend doing away with the FMP <-> ESS Table <-> FMP table use in the script. My experiences say that's where the issue is coming from.
I gave FileMaker about two hours at one point. At most it was retrieving 4,000 MSSQL records, so I would expect that would be sufficient time.
The relationship was from an ESS to a local table. The JOB layout above is looking at the ESS table. Jobs_Cached is a TO pointing to a local table.
At this point I'm working on a workaround that just does the search with local tables and imports (actually, creates records) from the external tables. I'm far enough along that route to continue and I think it'll work. FileMaker is sometimes annoying because it just works in so many cases that one often expects it to do so in edge cases and it doesn't, but it's pretty great because I've always been able to find some sort of workaround, as is the case this time.