Not sure that there is, but I always viewed "go to field with no field" as a way to change the focus, not actually commit data back to the table and close the record's "open" state.
You might use a get function to check the records "open for editing state" before and after you run go to field. I don't think the record is actually closed and the data actually committed, but I could be wrong about this very easily because I haven't used go to field like this in years--because I have this other script step called Commit Records.
LOL - as my Grandfather used to say ... "If it ain't broke, don't fix it."
I just need to change my old-fashioned ways.
As far as I can see, there isn't any difference from a functionality perspective, though I would love to know from an FM engineer what happens differently in the back-end.
The advantage of Go to Field versus Commit Record if you are using them without engaging their additional options (Select/perform or Go to target field for GTF; Skip data entry validation and Override ESS locking conflicts for CR) is that with CR you have to take the extra step of toggling With dialog: Off.
Every click counts.
(With that thought, wouldn't it be great if FMPA would remember how you set toggles like this on each script step, and then would use your last selection the next time you use that step? Or allow you to set a preference. I'm sure that 95% of the time we use one of the options over the other, but if the other is the default, you are SOL.)
Edit: This is in response to a post that has since been deleted.
That's not what i see.
Go to Field 
Does not leave the focus in the current field. I just tried this in FMP 15 to test and after running the above one line script, get ( activePortalRownumber ) returns 0, not 3--the number of the row where I'd clicked to put the cursor into the field.
I stand corrected! Go to Field and Commit act the same with portals in v15. I apologize for the bad info above, I deleted the above post to eliminate confusion.
Thank you philmodjunk for the clarity!
From the FM Help pages:
1. Re Committing—
"Data is committed when you:
• click outside of all fields in a record"
2. Re Commit Record/Request Script Step—
This script step exits the current record or, updating field data and making no field active."
My conclusion from the above is that there is no material difference in what actually happens. The biggest difference, therefore, is the additional options available with Commit compared to GoToField().
So far, I'm encouraged. But as suggested, some FM engineer knows the real reason. It'd be nice to know myself.
email@example.com , no problem with the deletion, but I recommend strike-through instead. I continue to make mistakes on this forum, attempting to help, and (usually) use the strike-through to help with continuity. Thanks to all for feedback.
will do ... I wasn't sure, but I agree deleting seemed odd.
in the order of operations exit object event happens right before commit. OnObjectExit and OnRecordCommit are both pre so not much diff there
It's all good. It's an obscure question, apparently.
I don't think I'm supposed to quote the FTSA, so I'll direct y'alls attention to the article "Editing Related Records through Relationships".
It appears that one can use Commit or Revert after looping through a related set of records. I'm not sure if it must be in a portal. From what I read, Commit is used in conjunction with Revert Record, Get(LastError) and Allow User Abort off - see "record locking".
See the Geist Interactive site for info on database transactions.
Creating a series of records via a portal is all one database transaction and revert records will revert all the new (or edited) records created/changed via that method all in one Revert.
This can also be true for other methods used to create/modify data in a related table such as using a global field to create and modify related records.
The trick is that no action can be allowed to take place that will commit records before the entire set of records are modified or created. This requires doing it all from the context of a single parent record without any layout changes.
Phill said, "The trick is that no action can be allowed to take place that will commit records ..."
Does that include Go to Field? Because that would, again, render the two script steps equivalent (with the exception of ESS and validation options suggested in keywords 's #6).
p.s. this is apparently a highly viewed topic. Thanks for all responses.
1 of 1 people found this helpful
Go to a specified field will not commit the active record, but go to no field would—as in Go To Field ( )—as this is the scripted equivalent of clicking outside of any field on the layout.
indeed - To Go to Field, or Commit Records? That is the question.
So far, you have the most relevant answer, in my mind. (No offense to the other valuable input and inputters.) It sounds to me like the two script steps are equivalent, with the exception of the ESS and validation options available with Commit.
As an aside, I've never considered reverting changes to a related set. I tend to work with one record at a time.