Fence, if you're admitting you made multiple changes to a relational field, I don't need a video. Since you're offering to still post a video, I guess you don't get the point to what I am saying. Let me spell it out.
If you select 5 files, and do an S&R on a relational field, it does the S&R 5 times, updating the field each time.
It EXECUTES THE CHANGE for the first file, then moves on to the second file, and EXECUTES THE CHANGE for the second file. And so on. So think:
What happens to the contents of the relational field after it does the change for the first file? Now what happens to those NEW contents when it does the change for the second file?
You're shooting yourself in the foot. Stop.
If you've ever gotten away with doing this in the past, it was because after the first change, the find string was no longer present in the relational field, and therefore all the subsequent changes were ignored.
Example for 5 files:
Relational Field Contents: I am silly.
S&R: "silly" -> "really silly"
Field Contents: I am really silly.
Field Contents: I am really really silly.
Field Contents: I am really really really silly.
Field Contents: I am really really really really silly.
Field Contents: I am really really really really really silly.
See what I mean?
Your Surname(G) example is EXACTLY this. Exactly.
So I hope you see why you got away with it before. Another example.
Example for 5 files:
Relational Field Contents: I am silly.
S&R: "silly" -> "thinking"
Field Contents: I am thinking.
Field Contents: I am thinking.
Field Contents: I am thinking.
Field Contents: I am thinking.
Field Contents: I am thinking.
The relational field was still processed 5 times, but after the first change, "silly" was no longer found, so no more substitutions were made. Get it?
Don't select multiple files, and then do an S&R on a relational field they share. Select only one file that shares the relational field.