I am curious how people deal with Record locking with their scripts.

Is there a way to kick someone out of a record? So your script can take control of it.

Or do you simply test to see if the records are available, then lock them? What happens if someone enters a record, while the script is running.

Entering a record does not lock it. Only editing a record locks it. But - yes, locking can be an issue and you might search for transactions as one approach. Depends on your needs. Maybe it is acceptable to loop through records and record IDs for unmodified records and process them later. Maybe you need to process all or none.

I thought "Open Record" forced a lock, even though the record had not yet been edited. "Commit Record" releases.

Well, true, but no mention has been made of opening the record.

Neither selecting a record nor entering a field opens the record. Only edits - or the open record command- does that.

I feel that handling record lock issues in your scripts (even paying attention at all) is a milestone in your FM maturity! Seriously, this is an issue that many developers just take for granted that FM handles it all for you. I remember the days of FoxPro, when the developer had to explicitly handle record locks. It was a good experience in two ways. First, I ran back to FM first chance I got, and second, I paid attention to record locks like never before.

With FMGo, the need for transaction-based scripting is more essential. That's the all or nothing. I find that easier than collecting IDs of records that were locked. Sometimes I loop around a script step that might fail bcs of record lock. Also, we often develop on live hosted systems. In define fields, we can be locking entire tables! All of a sudden, New Record fails! Yikes!

I'm curious whether the new table-mode ability to define fields produces any difference in response to record locking.

That is worth testing.

As it is I sit and cringe (definitely try to add fields off-hours). However, I often blissfully add a new field to a huge table and click OK--only to shout, "Oh no!" as I watch the progress bar. In fact, I need a post-it, "Are you sure that you want to click OK?"

That is worth testing.

As it is I sit and cringe (definitely try to add fields off-hours). However, I often blissfully add a new field to a huge table and click OK--only to shout, "Oh no!" as I watch the progress bar. In fact, I need a post-it, "Are you sure that you want to click OK?"

Just tried a brief test. Connected to remote file on my home FMSA11 dev server while away. Table view. Choose field options for a calc field, redefine the calc. Click OK to accept calc changes. Beach ball starts. Wait 1 second.

Pull the plug (ethernet cable).

Reconnect cable several minutes later, reconnect to database. No apparent schema damage, old calc expression still in place.

"No apparent schema damage" - could be famous last words!

I was hoping you'd also test if creating a field via the table view is faster than define fields, but I don't see how it could be.