Did I read this correctly, that they want to replace field contents on a found set in a repeating field? That raises more questions than it answers.
That could be done more safely via a looping script which could address individual repetitions and error-handling.
I don't know why the communications error might be happening, but I can image several problems with using replace on a repetition.
Is there any type of validation on this field? It's also possible that more than one user may be editing a record in the found set when the replace is invoked, which will produce an error regardless of the active field(s).
Let's hope the repeating field idea isn't part of the rebuild.
Yes, what you read is correct. They are using a Replace Field Contents in a repeating field in a found set, and they usually just mainly use it for the first repetition.
I can see what you mean about possible problems. I could write a script, but I don't know if it is worth the effort (I'll find out), if a new system is going to be in place soon.
Thank you, I will check on the validation, and I can try to deduce if someone is editing a record. (Didn't expect that as it usually has a different error.)
Nope, no repeating fields in the rebuild.
There doesn't appear to be any validation.
Still will check on the if someone is trying to edit the record.
Here is a result I got elsewhere:
"Best guess is that the file is damaged in some way that either the recover cannot fully repair, or some issue that originally damaged the file damaged it again at some point after the recover fixed it.
Things to keep in mind about Recover:
While Recover almost always detects and fully corrects any problems with your file...
- The recovered copy may behave differently even if recover reports "no problems found".
- Recover does not detect all problems
- Recover doesn't always fix all problems correctly
- Best Practice is to never put a recovered copy back into regular use or development. Instead, replace the damaged file with an undamaged back up copy if this is at all possible. You may have to save a clone of the back up copy and import all data from your recovered copy to get a working copy with the most up to date information possible.
And here's a knowledgebase article that you may find useful: What to do when your file is corrupt (KB5421)."
Tested with only one user in the system. There is still a problem.