I would like to know the difference between
Revert/record request and
How can I write a script for the revert record request?
FMP is "somewhat" transactional.
The script step is "Revert Record/Request". The 'record' is in browse mode. The 'request' is in find mode.
If you create a new record, start entering information and do NOT touch anywhere outside a field and do NOT go to another record and do NOT commit the record....
it can be 'reverted' to NOT being created!
It's also useful when editing. If you start typing and say "oops", you can 'revert' the changes.
Thanks for your time Beverly.
I am afraid I don't understand how to do it. Let me explain some more what I need to do.
I notice that people are introducing error in my database because sometimes they don't realize they are changing the records while for example trying to search the database.
So what I would like to set up is a script that upon diting a filed in a record triggers the question: are you sure you want to change the record ( or something lie that)? So I hope that people have to take a moment t think about what they are doing.
Hope this was clear and you can help.
Thanks a lot
Carmela, the 'revert' is only available until the record is committed, to it does not prevent the changes you are finding.
Developers have for as long as I can remember, have come up with a "edit mode" that is really a way to push a records data into a temporary record with fields or into globals. Allow editing there and then if "Are you sure?" is YES, push the data back into the real record.
You'd have to limit the access to the record (by account/privilege), so that not everyone can edit and you can disable the fields in "browse mode", so that they cannot be entered. If you allow entry in "find mode", then they can search and not edit the fields.
See the FileMaker Help topics on "Designing and creating databases > Editing objects on layouts > Selecting and working with objects on a layout > Using the Inspector to format objects" and "Designing and creating databases > Editing objects on layouts > Controlling data input behavior of fields > Allowing or preventing entry into fields". Uncheck the "Browse" checkbox under the Data tab in the Inspector for any field you want to limit.
Also see "Designing and creating databases > Protecting databases" and related topics on setting the account/privileges.
As for the "edit mode" table with fields or globals, remember to set/use the unique ID of the record to edit, so you can push the correct data back upon "submit".
Another thing you could do is write 1 script which displays a dialog with a global field to capture the field content and field name via $variables.
This script should use the "Set Field by Name" script step so you can target a field via the paramter.
Set each protected field as unenterable in browse mode, and make each field a button to call this script with parameters of the field's name and contect, then parse the variable and populate the global field with the content for the user to edit. Set the first button to continue with the edit so the edited content is saved to the globa, with a second dialog asking them to confirm the change (button 2 ! this time) but no field to edit. This way they can't edit and hit only default buttons. Button 2 in the second dialog would execute the Set Field by Name step to write into the actual field and then clear the global.
Keep in mind that this will make yor users feel like they have to jump through hoops to edit, but it will provide pretty solid protection against accidents.
You can also set the script to check Window Mode so that it goes directly to the field in Find mode. A single script will handle ALL fields if the parameter is set correctly via the button-paramter on each field.
Yes, you can force the system to request confirmation on a commit. Here's how:
1) Go into Layout mode.
2) On the layout where you want this to happen, select "Layout Setup" (the little pencil icon or via Layouts / Layout Setup).
3) On the first tab (General), uncheck the box that reads, "Save record changes automatically".
This will produce a dialog each time the user tries to commit a record. It will meet your basic requirement.
It may not be very elegant. Try it and see if one of the more sophisticated solutions suggested by Beverly or Stephen isn't better.
Retrieving data ...