5 Replies Latest reply on Jan 10, 2011 1:05 PM by KenKing

    Best Practice for Records Check before New Record Committed?

    KenKing

      Title

      Best Practice for Records Check before New Record Committed?

      Post

      Hello all, 

      I have a "property" table listing every unique property coming through the company. I also have a "deal invoice" TO, which is related to the Property TO. 

      My goal is to have the user input a Property on the "Deal invoice" layout, then check to see if there is a record of that inputted property in the "Property" table; if not, then add such user input as a new property then set field "DealInvoice::PropertyID" as the new property; if record is Found, then use such found record as the value to setfield "DealInvoice::PropertyID".

      Im looking for the "Best Practices" approach for the above (which I believe will be a script).  I can probably string together something (like setting a local variable using a newly created field for the user to type a Property name etc...also, I've got validation set up, but I think validation only gives me an answer (the input is valid or is not), but not sure if I can use validation results  as a variable in a script?.  Also, not sure how best to get the Users input into the script?

      Anyhow, I'd like to do this in the most effecient manner.  Any suggestions?

        • 1. Re: Best Practice for Records Check before New Record Committed?
          RickWhitelaw

          If you check out Error Messages in the Help file, you'll find more than one error message that relates to failed validation. You can trap for these errors in a script. As well, as I'm sure you know, you can have FMP display a custom message when validation fails. Once you determine which errors to trap with Get(LastError), and there are many ways to script this trapping using the "OR" operator, you're on your way to where you want to be.

          RW

          • 2. Re: Best Practice for Records Check before New Record Committed?
            philmodjunk

            Sometimes I set validation rules for the fields, but then use script triggers to trap for the same error. The validation rules make sure that any scripting omissions/errors on my part do not keep the errors from being trapped, but use the scripts to provide a more responsive, and less confusing series of messages trapping specific errors. (You can't set up a custom validation error message that includes a calculation or that presents different messages for different errors, but you can present such messages via scripts that use Show Custom Dialog to inform the user that an error has occurred.

            • 3. Re: Best Practice for Records Check before New Record Committed?
              KenKing

              Thanks for the responses.  I set up the Error trapping Rick describes, and I'll employ the "double layer" protection PhilModJunk described (validation + error trapping). 

              I've got the script working now, but I have a question for you: I've heard to avoid using global fields unless necessary, and Im wondering if Im setting myself up for problems down the road.  

              Here how the global field works with my script:  Im using a global field I defined specifically for this script, and placed it on the "deal invoice" layout.  A button triggers the script, which brings up a custom dialog box, which has an input field based on the global field. The script performs a find (on the "Properties" TO) based on the input; then the script branches depending on $LastError (401 or 0).  As an aside, I realize the "perform find" may result in a found set of more than 1 property.  But I figure one problem at a time.

              Any recomendations?

              Thanks for the help.

              • 4. Re: Best Practice for Records Check before New Record Committed?
                philmodjunk

                I wouldn't dream of developing in FileMaker without using global fields. Granted, the new global variable based options remove the need for using global fields in a number of situations, but there remains many, many situations where the only practical solution is to use a global field.

                Using global fields for scripted finds, is one of the classic uses for which there is no better alternative. If you downloaded my Known Bugs List database, you'd find it uses the exact method you describe, but with a few extra bells and whistles. (I use a new window command so that I can use formatted fields and a portal when collecting criteria from the user.)

                • 5. Re: Best Practice for Records Check before New Record Committed?
                  KenKing

                  Hey that's great, glad to know Im on the right track.  

                  I've downloaded your linked DB, thanks for that. I've found that dissecting other people's databases is a great way to aid FM learning, so thank you again.