I'm wondering what method folks are preferring for scripted creation of related child records in FM GO.  With Pro I would generally store the parent ID in a local variable, change layouts to a utility layout of the related table, create a new record, set the parent ID, set a other data as needed and then return to the original layout.  This seems ponderous in the GO environment.  How are folks doing this with GO.

That's how I do it. Doesn't seem ponderous at all.

 

I also use an off-screen window to do all the scripting in.

The subject here is FM GO.

 

Where there is  no such thing as an off-screen window.

 

I prefer the auto-create method using global fields. No need to change layouts.

That's a bit of a quibble, Bruce.

 

On FM Go creating a new window and then closing it won't show any intervening screen changes. Just iOS's default spinning circle until the script is complete. The benefit of a new window is the user doesn't lose their place. I use an "offscreen" window since I use the same script for Pro and Go.

 

Global creation is ok, but it takes some schema overhead: a global field, an additional TO, and a relationship for each table you want to create child records for.

There's some schema overhead with creating related records without switching context, but switching layouts is a relatively slow way to create records, and opening new windows is even slower — both of which need an "escape hatch" mechanism if the user aborts the script before it's done with those contexts. Creating records transactionally without leaving the layout where the script started removes the need for the escape hatch, performs faster, and it's transactional so that the whole operation can be easily reverted in the event of an error. It's especially faster in the event of a FileMaker Go app connected over a network, since very little needs to be saved over the network until the transaction is committed.

Here's a file to test with.

(file updated)

SimpleListOfB.fmp12.zip

Looks like using globals is slower...if you take out the Commit[] inside the loop of the New Window method (or add a Commit[] to the global loop). This is being tested locally with 5000 per loop.

 

I suspect globals may be faster if you're only creating one or a few records. But then the difference wouldn't really be noticed anyway.

 

The transactional aspect is useful, but for single child record creation I'm not sure if it matters.

Hm. Either on device or LAN that is not the result I get. Modified file shortly.

SimpleListOfB.fmp12.zip

A few more mods.

SimpleListOfB.fmp12.zip