10 Replies Latest reply on Oct 16, 2016 5:53 AM by wimdecorte

# Skip or Omit ... potential pitfall

I propose to you the following:

Two bits of code - I think the first one is fine, I think the second one has the potential for problems:

First, a walk in the park ...

Then, enter the Twilight Zone ...

Given a set of five records, if the fifth (last) record meets \$condition=1, then the previous existing record's Main::OrderTotal will be evaluated twice and \$grandTotal will be incorrect.  I recommend the following modification to the "Omit Record" step ...

- the Set Variable \$condition was intentionally left empty.  It should say // your Boolean logic here

• ###### 1. Re: Skip or Omit ... potential pitfall

When you set the variable \$condition you don't give it a value?

• ###### 2. Re: Skip or Omit ... potential pitfall

I believe David left out that part of set variable on purpose. Insert the calculation of your choice as a way to control what happens next.

I've seen this issue before.

• ###### 3. Re: Skip or Omit ... potential pitfall

Or perhaps If \$condition=1 is the same as If \$condition which is how I would do it.

• ###### 4. Re: Skip or Omit ... potential pitfall

If [\$condtion = 1]

and

If [\$Condition ]

are functionally identical, but David doesn't actually include a calculation that changes the value of the variable. Presumably that was intentional as a form of "pseudo code" here.

Of course if the only reason for the script is to compute the total, there's no reason to omit records. But presumably, a found set of just the records that contribute values to the grand total is also a desired result here.

• ###### 5. Re: Skip or Omit ... potential pitfall

Yes, the \$condition was intentionally left empty.  It should say // your Boolean logic here

And, the \$grandTotal was used to demonstrate the potential error.  I could have thought a bit harder and come up with something more disastrous.

• ###### 6. Re: Skip or Omit ... potential pitfall

I tend to be too explicit in my code (not including the half-pseudo-code above).  I used to use GetAsNumber(\$number) = 1 or \$number = "1" because FileMaker explicitly states that all \$variables will (must) be evaluated as text, yet it handles \$variables as if they have a data type (implied).

• ###### 7. Re: Skip or Omit ... potential pitfall

If the resulting found set is not important you could also omit the records that do contribute to the grand total.

Or keep a list of record IDs handled and check whether you have before adding to the grand total ( FilterValues() )

Or you could do an executeSQL to gather the values with the condition built in, then loop through the result of the sql query instead of looping through the records

• ###### 8. Re: Skip or Omit ... potential pitfall

And with ExecuteSQL you don't have to loop through records in a script at all, you could just use the sum function to sum the records within the query itself.

But this is all besides the point of David's demo--which is to point out a significant pitfall in this type of commonly used looping script.

• ###### 9. Re: Skip or Omit ... potential pitfall

That's why when are doing conditional omit/skip records you need to set your loop to the number of found records and exit after processing all records, not based on if current record meets condition X.

• ###### 10. Re: Skip or Omit ... potential pitfall

philmodjunk wrote:

But this is all besides the point of David's demo--which is to point out a significant pitfall in this type of commonly used looping script.

It wasn't clear to me that David's post was not a question or a request for alternatives... so forgive me for thinking it was to the point.