1 Reply Latest reply on Aug 13, 2015 11:25 AM by philmodjunk

    Forced to Enter Data in a field that has "not empty" validation, even if the field is not on the...

    skashanchi

      Title

      Forced to Enter Data in a field that has "not empty" validation, even if the field is not on the layout?

      Post

      So I have a table with several fields that have their validation set to "not empty". 

      I have several different layouts that create records in this table. I use different layouts for creating records, because there are different ways in which records are created by users, depending on their job function. So some layouts have fields that other layouts do not. The problem I am having users are getting a message saying that a certain field cannot be empty, even though the field is NOT on the layout?? Why is FMP requiring a user to enter data in a field that is not on the layout?

      Is it the case that when you assign "not empty" for a field in a table, it expects every record created for that table to have data in that field, even of that field is not used in the current layout creating a record? If so, then what is the proper way around this? Do I need to use layout scripts to require fields to not be empty, instead of assigning that attribute to the field itself in the database?

        • 1. Re: Forced to Enter Data in a field that has "not empty" validation, even if the field is not on the...
          philmodjunk

          Why is FMP requiring a user to enter data in a field that is not on the layout?

          Because the field's validation requires that the field not be empty. This validation option does not depend on what layout is used to edit data in the record. If there are cases where the field is allowed to be empty, remove this validation. If it must always have data, you will need to provide a way to add the needed data no matter what layout is used.

          The best way to fix this depends on what needs to happen with this data. There can be many different design options that might be used in this situation. Why was this validation specified in the first place? What are the circumstances where leaving the field empty can be permitted?

          Validation field options are useful as an "insurance policy" that makes 100% sure that a particular error does not take place. But the validation error messages that pop up are "clumsy" in my opinion as the message content is limited and the options presented to the user can be confusing or even options you don't want them to choose. They also allow the user to make the error and then the message appears and requires them to correct it.

          A better interface design is one that, if possible, prevents the user from making a data entry error in the first place. Of course, this is not always possible. When you do need to check recent data entry for errors, a script run from the OnObjectValidate trigger allows you to provide a much more flexible and user friendly response to errors with better and less confusing options for correcting them.