What you have described does not prevent user modification.
"do not replace existing value means that if data exists in the field, the auto-calculation is not allowed to compute a new value and replace the existing value with the new. It does not prevent the user from entering a different value.
Use privilege set option in Manage | Security to control access to the record in which this field is found, use interface design methods--such as two copies of the field--one that allows access and one that does not with Hide Object When controlling which copy is visible, or field validation rules that reject user input based on a calculation that controls whether a value may be changed or not.
In 1. do you mean my field description should not preclude data entry?
Manage|Security: I'm not quite getting "use interface design methods--such as two copies of the field--one that allows access and one that does not with Hide Object When controlling which copy is visible, or field validation rules that reject user input based on a calculation that controls whether a value may be changed or not."
2. Any thought on why there's a time expiry after which a User can't modify records?
I mean that this auto-enter field option does not block users from editing the field. That not what it is designed to do.
Manage security is one option, but controls access to an entire record and thus may not be workable.
Interface design options covers a whole list of methods that might be used. Some are better at blocking user modification than others. All are far less secure than Manage Security.
Validation options are a third option that allows the user to make changes, but then displays an error forcing the user to revert the change. This is much more secure than UI options, but much less user friendly. Often the best option is to use UI methods to "keep it friendly", but also employ a validation rule to ensure that if a user finds a way around the UI methods, the user is still blocked from making changes.
2. I have no idea what you mean by "Why". There is no such thing as a built in feature of FileMaker though such can be employed via Manage Security if you want.
Just checking: You're saying there's nothing obvious in 'Manage Security' that would have a 'timer' locking older records?
It's a puzzle to me because I don't remember setting anything along these lines for the User Runtime and it definitely isn't active when logged in as Administrator.
It is quite possible that record level access could be set up to block edit access to records of a certain "age", but a specific calculation would have to be put in place.
1. The solution originates on a Mac and when logged on as a User doesn't prevent changes to previous records. The latter only occurs on the PC Runtime version.
2. The RT doesn't permit changes to records >5 days old, but it could be less; I'll narrow it down.
3. There are 3 related tables involved: Calc < IO < FU. IO does appear to permit changes; Calc and FU don't.
I'm still inputting records to see what triggers the problem.
What you describe doesn't really make sense. It is possible for the entire run time file to be accidentally made read only at the file permissions level--an OS setting that you can check by checking file properties from a right click of the file.
But being able to modify some records and not others is usually controlled via manage security and those settings would change behavior from Mac to Windows nor from regular FielMaker to RunTime.
What happens to tell you that you can't edit the data?
Can't enter the field?
You get an error message? (If so what message?)
Typo in last post:
Those changes would NOT change behavior from Mac to Windows to run time...
The message is: "Your access privileges do not allow you to perform this action."
However, I've check Manage>Security and there doesn't appear to be anything relating to time elapsed.
What DO you find?
There is a section the can be set up that controls record and field level access.
Can you find that section?
Yes, I'd checked those..........but your post made me check again. The calculation I'd got worked, but I'd not updated my export/ import. This meant that the vital fields with the calc had no data. I've not fully checked (will update that post if I'm wrong), but I think your suggestion was correct.........I'd just added a layer of complexity that cloaked the problem!
That sounds right. A null (empty) result in this expression will be treated as False and that would deny access.