Peter, it sounds like you've left the "allow create" on for the table. If you don't want edit abilities I would suggest disabling "create" as well.
What is happening is it is allowing them to edit the record during creation, before the record is committed to the database. After the record is committed, it falls under the "edit" rule you set.
Try disabling under the "create" column in the table priv. settings and see if that works for you.
I see your point, but why would I be able to edit them once I have committed the records?
newly created but un-committed records "technically" do not exist yet in your database. It's a transactional system, until you complete the transaction the data is not saved, so the rules do not apply to it.
I am thinking that you are able to edit records you have created, but NOT committed. Try creating a record, not making any changes, and clicking outside of whatever field the cursor is in (to exit/commit the record), then try to edit again. Can you edit now? Or could you only edit immediately after the record was created and you were in a field?
Turning off the "create" privilege allows you to account for this transactional rule, and avoid any confusion. It should be turned off anyways from what you've explained about your solution, unless I misread that you wanted your users to create a bunch of blank records somewhere in a table?
It is understood that records set to Can Create and Can't Edit in the Privilege set for Tables allow users to generate new records and edit those records generated during that session until the file is closed.
Once the file has been closed and re-opened, then all records are locked and cannot be edited - but new records can be created and edited (until the file is closed).
This is unaffected by un-committed or committed records - they can all be edited if generated in the current session.
ptrc, you may want to turn off Create as well as Edit and see if a script set to 'Full Access Privileges' will allow you to generate and manipulate new records in the way that you want.
Best wishes - Alan Stirling, London UK.
+44 (0) 20 7724 2456 - firstname.lastname@example.org - www.ast.fm.
FileMaker Certified Developer for versions 7, 8, 9, 10, 11 and 12.
Alan, I could have sworn I've seen different behavior, but I've almost never used a combination of privileges in that manner. Any documentation that points to this behavior (I can take your word, but I hate the "it is understood" catchphrase), as it's not listed in the official guide:
Although it does state:
Note Avoid creating inconsistent combinations of view, edit, create, and delete privileges.
I created a sample file on my mac to play around and ran into an interesting behavior. The attached file logs on as "test" (no password), with a "test" privilege set, set to allow view, create and delete with access to all fields, but EDIT is turned off. Create new record is completely blocked in this setting, no new record creation is possible. you can log in holding down option, admin (no pass) to verify I set up the priv. set correctly.
Was this behavior different in 11 than it is in 12?
Untitled.fmp12.zip 7.9 K