If the data is IMPORTED, just goto layout>format>field control and set to not modify in browse or finf mode.
If you are manually entering data, set a trigger on object modify to display a warning if someone tries to change - hope this helps.
Sorry - just noticed you have FMP9 and not FMP10
For manual, you should change PERMISSIONS for different users that you do not want to change that field. One ADMIN should be able to change - make sense?
Create a script that look at the field to see if it contains data. If it does, and you are not in browse mode, then the script exits. If it does not, the script navigates to the field then exits.
Now make the field an inaccessible field. Make the field a button that launches the script described above.
How important is it that the field not be changed? The only truly safe way to protect from change is to use accounts and privileges (as said by Webflys in last post). Using layout controls or script triggers will fail to protect data because someone can access the field from another layout or another file or even import.
A 'lock' for the field would be similar to: not isEmpty ( theField) ... which would give permission to change it (to that privilege set).
If security is the issue, there is little one can do at the field level. FileMaker Pro's security model allows calculated control to the record level, not field level. Yet in this case, calculated control is needed to determine the empty state of the field.
Creating a secure model that would accomplish the goal of allowing edits to empty fields only is complex. One would need to allow access to the record only to the [Full Access] account. A shadow layout would need to re-create the target table's fields for data entry. A script with [Full Access] priviledge would then be required to enforce the data entry rules and modify the target table's data with the shadow layout's data if it is OK. Access to the script could then be weaved into the security model.
Oh right, David, it would stop editing on full record.
David said, "Creating a secure model that would accomplish the goal of allowing edits to empty fields only is complex. "
Nah, security can be achieved on field level anyway ... using validation and, unless the person attempting illegal access (through another file or whatever) has the proper full access account, they can't change it. I see no need to go through the complexity you indicate in your last paragrah. Validation on the field would be:
IsEmpty ( field )
Get ( PrivilegeSetName ) = "[Full Access]"
I admit I usually dislike field level validations. You said 'if security is issue', well, if someone asks how to stop data being changed,they may think it means only the current layout but they don't think that, if they create a report with that field, it will suddenly be open to edit on that report. They may not know that someone can use that file as external source and create a relationship to it and have open access to changing the data in that field.
Simply, they may not know about all the holes and it is important to mention that layout control and script triggers will not properly protect because they apply to the version of the field placed on a layout. You need to go to field level or privileges to properly control.
Field level validation occurs on the new value, not the old. You could not check to see if a field was previously empty to see if it could be edited. Validation occurs after edits.