# New Loop options in v20.3 **URL:** \ **Category:** Questions\ **Tags:** scripting, loop\ **Created:** [November 22, 2023, 1:10am UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804 "2023-11-22T01:10:35Z")\ **Posts on this page:** 8\ **Page:** 2
**Author:** ![Bobino](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bobino/32/194_2.png) [@Bobino](https://the.fmsoup.org/u/Bobino)\ **Post date:** [January 18, 2024, 4:36pm UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/21 "2024-01-18T16:36:53Z")
There is a recent Claris Engineering Blog post that discusses that specific topic. Check it out here: [ClarisPKB](https://support.claris.com/s/answerview?anum=000040663&language=en_US) ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [January 18, 2024, 10:18pm UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/22 "2024-01-18T22:18:50Z")
Two ideas: 1. The Blog post notes that behavior is different with relationships that are one, vs. more than one relationship away. I wonder if this has anything to do with the bug discussed [here](https://the.fmsoup.org/t/fms19-6-3-poor-performance-on-m1-mini-ventura/3372) that only shows up when dealing with data 2 relationships away? 2. Does "Replace Field Contents" behave the same as a Loop with Flush:Always ? ---
**Author:** ![Bobino](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/bobino/32/194_2.png) [@Bobino](https://the.fmsoup.org/u/Bobino)\ **Post date:** [January 20, 2024, 12:01am UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/23 "2024-01-20T00:01:40Z")
I would assume `Replace Field Contents` to behave like a `Set Field`. If there is no loop involved, then it behaves as it always has, if it is inside a loop, I expect the loop option to be honored. ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [January 20, 2024, 2:28pm UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/24 "2024-01-20T14:28:14Z")
The issue is that RFC iterates over the current found set, so, in many ways, it behaves as if you are doing set field inside a loop. If so, the question remains: when does data get flushed? ---
**Author:** ![steve\_ssh](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/steve_ssh/32/160_2.png) [@steve\_ssh](https://the.fmsoup.org/u/steve_ssh)\ **Post date:** [January 20, 2024, 5:03pm UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/25 "2024-01-20T17:03:22Z")
> The issue is that RFC iterates over the current found set, so, in many ways, it behaves as if you are doing set field inside a loop. If so, the question remains: when does data get flushed? Hi @xochi, I thought this was an interesting question, and did my best to create a simple test file to run an experiment to attempt to have an answer. It's morning here, and so I may not be thinking it through correctly, so apologies if it turns out that there is some blunder in what I set up. I'll attach the file here. The result that I see is that, on v.18, RFC continues to honor a relationship that is broken as part of running the replace. In other words, unlike a loop with "Always" flush, the join results are not updated until after the replace has completed. That said, I definitely invite you to check my work, and should you be so motivated, try out the same test in a recent version of FMP, with variations on the flush option of the loop step (I am not at a computer where I can do that, right now). ![RFC Test Setup](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/e/ef6200a52620b259c7842892d960a3a827aa7350.png) [RFC\_20240120A.fmp12.zip](https://the.fmsoup.org/uploads/short-url/mSq04b3qJKHAeBe1NpmQPsUgwx8.zip) (71.6 KB) ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [January 24, 2024, 4:46pm UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/26 "2024-01-24T16:46:48Z")
Thanks @steve_ssh - I haven't had time to dig into it, but the possibility that RFC and Loop behave differently would definitely be important to know in certain situations. ---
**Author:** ![xochi](https://avatars.discourse-cdn.com/v4/letter/x/0ea827/32.png) [@xochi](https://the.fmsoup.org/u/xochi)\ **Post date:** [February 14, 2024, 1:24am UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/27 "2024-02-14T01:24:19Z")
@steve_ssh I finally got around to testing your file. I added some new variations, testing these modes , running in FM Pro 20.3.1.31: - RFC (replace field contents) - Loop [Always] without Commit - Loop [Defer] without Commit - Loop [Always] with Commit - Loop [Defer] with Commit The results: - only RFC was able to use the value from the previous record even though we changed the key during the calculation. - all other Loops behaved identically At the moment, I'm not sure how I feel about this, other than "Hmm, that's odd." Is this a bug? Undefined behavior? Expected behavior? To summarize: when setting a field's value (A), and the field triggers an auto-enter calc in another field (B) and B is a key used in a relationship (and that relationship is being used to set the value of A), then behavior is different depending on whether you set A using **RFC** or a **Set Field** script step in a loop. RFC seems to break the relationship after the field value has changed, whereas Set Field seems to break the relationship before. The new loop options in 20.3 seem to have no effect on this behavior, nor does having a **Commit** script step in the loop. Revised file: [RFC\_202400213.fmp12.zip](https://the.fmsoup.org/uploads/short-url/QCm1lfuWgiKtTiuEurqUt9R60R.zip) (76.3 KB) To run the tests, just hit Command-2 through 6, and you'll see a result dialog like this: ![image](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/3/3638040630898489442c0fd671ea7eaab5d759b9.png) ![image](https://canada1.discourse-cdn.com/flex030/uploads/fmsoup/original/2X/b/b7e253d933299b770d7e0ccb453203ff6323d760.png) ---
**Author:** ![Kirk](https://yyz2.discourse-cdn.com/flex030/user_avatar/the.fmsoup.org/kirk/32/2197_2.png) [@Kirk](https://the.fmsoup.org/u/Kirk)\ **Post date:** [April 4, 2024, 3:15pm UTC](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804/28 "2024-04-04T15:15:11Z")
From a blog post on another site (may/may not be relevant): Since the beginning, two events have been distinguishable in the way of modifying data: drag and drop and Replace Field Contents. Indeed, these two events have the particularity of being able to operate on records not previously opened, to modify the records, and to keep them “closed”, without triggering an OnRecordCommit event. Well.....great news: window transactions can now capture these events. If the active record is not open when you start a replace action or drag content onto a field, then a window transaction will be triggered after the event. [Previous page](https://the.fmsoup.org/t/new-loop-options-in-v20-3/3804.md?page=1)