There is a recent Claris Engineering Blog post that discusses that specific topic. Check it out here: ClarisPKB
7 Likes
Two ideas:
- 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 that only shows up when dealing with data 2 relationships away?
- Does "Replace Field Contents" behave the same as a Loop with Flush:Always ?
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.
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?
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_20240120A.fmp12.zip (71.6 KB)
5 Likes
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.
1 Like
@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 (76.3 KB)
To run the tests, just hit Command-2 through 6, and you'll see a result dialog like this:
3 Likes
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.
3 Likes