There are ways to make a record not editable that do not require moving the record to a different file or even a different table. What is the reason for moving it to a different file?
Whether keeping the record in the same table or not, Manage | Security can be used to deny edit level access to a record. This can be done on a record by record basis if the only reason to move the record is to keep it from being edited.
See "Editing record access privileges" in FileMaker Help and check out this particular sub section: "Entering a formula for limiting access on a record-by-record basis" for a description of how to set this up.
HI Phil....thanks for your reply. The reason the the file to be moved isnt for security reasons but that the file would be no longer needed to be kept in the orginal file.
file1 is a goods inward file that has a field that asks...do the goods need to be tested? yes/no ....if yes then the whole record needs to be moved to file two , the data moved isnt to be changed in anyway hence my desire to have it un-editable. The person testing the goods accesses file2, can see what goods need to be tested..then proceeds with entering the rest of the data
what the data processor of file1 would see on the screen is click yes button then a new record for the next data entry
what the script would do is ..if yes then open file2 move record , make the record non-editable, close file2, open file1 and create a new record
I hope this is a little clearer and thanks again for the help.
I don't see any reason for two tables, let alone two files. A user can go to a layout, and that layout can be set up to only show the records for goods that need to be tested automatically. The layout can be designed to prevent the user from ever seeing the records for goods that no longer need to be tested and Manage | Security can be used to lock out any edits by users that do not open the database with a full access password. This can be done without moving the records to a different table or file and can offer a less complex structure with greater flexibility for reporting and analysis.
But what you want to do can be done with Import Records if your script first isolates that one record in a found set of just that single record or you can use a relationship based on a primary key and use a script to copy over the primary key with looked up value settings that look up the data from your original table. In either case, after the data is copied to the other table(the table can be in the same file or a different file), your script would delete that record from your current table.