Hello,

I have a simple if statement (simplified):

 

If [myTable::Value < 0]

    [result 1]

Else

    [result 2]

End If

 

The thing is, I get [result 2] even if Value is less than zero. The only thing I could think was that on the current layout Value is displayed as part of a text box (i.e. "Some text <<myTable::Value>> some more text"), but testing this by adding a field for Value doesn't seem to fix it.

I am completely stumped.

Is the myTable::Value field a number field, a text field, or something else? If it isn't a number field, using GetAsNumber ( myTable::Value ) instead may clear-up the issue.

It's a calculation with the result as a number.

 

I've sort of figured it out. Earlier in the script Value is used in a different IF statement, and after that Value is changed, and then the IF statement I'm having a problem with happens. I added a dialog pop up showing Value just before the problem IF statement and Value in the dialog box is the same as in the previous IF statement. In other words, Value is being cached when it gets looked up in the first IF and then the same (old and incorrect) value of Value is being used in the second IF statement. I know the changes to Value between the IFs are happening because I see them happen on the layout as I step through the script in Debug Mode.

 

So I guess my question now is how do I get the script to look up the value again instead of just re-using the old one?

 

e: Relookup Field Contents gives me an error dialog and Flush Cache to Disk doesn't work either.

You probably need to Commit Records after modifying the field's value (you're not providing sufficient information to enable us to reproduce the problem).

Cool, putting a Commit Records before the second IF fixed it. Thank you, I would never have thought of that. I have never used Commit Records before, is it good practice to Commit Records after every manipulation step?

is it good practice to Commit Records after every manipulation step?

 

No. I recommend you download the Migration Foundations and Methodologies white paper and read Ilyse Kazar's article about record ownership starting at page 73.  New to version 7, and still very much needed and relevant.

The other consideration is that, when on iOS, it is important NOT to commit a record needlessly since each commit sends all the record's fields back up to the server.  If a User is in the habit of clicking the layout as an act of committing, it can really slow things down. One can use a layout which prohibits commit (via button or web viewer over entire layout) and forcing a button 'save' action.  This stops repeated unnecessary record movement.

Ah, I see it was just the link duplicated.

 

Thanks for the catch! Fixed now.