How we can get an warning popup message on every data field to avoid incidently editing or we go for editing any data field(Once data have entered).
Please define "avoid incidentally editing" and "editing any data field(Once data have entered)." more precisley so we can help you.
I dont think your gave us enough to go on.
You can change the privilege so that the users do not have permission to make changes. Or in the layout, you can change the field Data attribute in the Inspector panel to now allow users to browse into the field. But these also prevent the user from making changes. You could make each field a button that runs a script with Full Access mode and prompts for the change in the field and asks them to confirm. Or you could go to an Audit system that records every change so that you can roll back any bad editing. As cohenrentkris said, we really don't know the whole story on what you are trying to achieve and what your security requirements are.
Thanks to above replies
In brief my queries is as such is there any script for locking and unlocking any data field. As we put any data in any text/numeric indexed field and after saving the page or table it should be automatically locked. While further if we again visit to page or table and browse that page and want to modify any data field it should popup message "Do you want to modify field" . This should be command by two buttons "Yes" and "No". If we push "Yes" button the field should be unlocked and on "No" button the page data field will retained locked. The script will work only on text/ numeric data field not on calculation field. some other example is in png view
You should review "commit" in regards to FileMaker as it impacts ... "after saving the page or table". Filemaker is not a traditional app where you have to explicitly save a record. To implement such a strategy requires a deep understanding of the workings of FM. Search for any of Todd Geists work on transactions and you'll find some great info on how to do this. I would say that to attain your goals as stated above may require some kind of transactional aproach. The other thing to research is the security model and field validation. Sounds like you want to implement a data security feature in the GUI which is always problematic per our security experts.
The reason that im suggesting all this reading and research is that what your asking of FM may not be easy and seems fraught with potential "gotchas"
+1 for what coherentkris says. I think what you propose will make FileMaker unweildy for the end users. One solution is to have a validation field that only lets you edit other fields in the table if you have turned it on. All of the other fields validate to when the Edit button it turned on and once turned off, you can't edit. You could also do things like make all of your fields uneditable and if you hit an edit button, it takes you to another layout that allows for editing. Or, as coherentkris says, you can have a transctional model where you are editing data in a different table different or file that is then trasnactionally copied to the permanent table after the edit is complete. There are a number ways to address your concerns, but you do really need to understand how FileMaker handles record locking. Ultimately, the big problem you have is that you only want people editing records when they are supposed to and not when it is by accident. FileMaker will never be able to read a persons mind and tell when something that is typed is wrong or right, only whether they have permission to do it at all. Maybe FileMaker version 20 will be able to read our minds and intentions... until then, this is what we have and all things considered, FileMaker gives us pretty good control through security and validations.
If you want to prevent someone just fumble-fingering data into a field, one thing you can do is to turn off the "Save record changes automatically" checkbox in the Layout Setup dialog. This will cause FileMaker to throw up a confirmation dialog for the user if changes have been made so he has a chance to revert changes if he made a mistake (rather than having to select "Revert Record" manually).
It's a simplistic solution, but might stop the problem you're describing.
This is what i want
Retrieving data ...