Returnvalue from refresh()

Sometimes it would be nice to know if a function performed an action. For refresh() it would be nice if it returned a true or false when (not) done in a certain amount of time.

1 Like

Maybe you can figure out something with delay().

In my opinion, delay will make it worse - I don’t think that function addresses this type of problem. If you delay the action, that will apply to everyone hitting the button, but if you don’t have an updated instance of the doc, delay does not change anything for the 2nd (and more) users working with data that is not up to date.
Refresh() before the button option continues its action would solve the problem: my function looks at a status value in the current row and if that would be refreshed before the button action continues it would not perform any unwanted actions.
Now the (potential) problem is one or the other of the following 2:

  1. the refresh does not refresh from the server, but the button action continues (I have tested that with offline processing the refresh, which per definition fails because you are offline, but since there is no fault detection, you can’t divert the program logic)
  2. it does refresh from the server, but it processes the information that is in the row as it was before the refresh takes place).
    I am not sure about 2), because there is no way for me to check what really happens under the hood. The only think I know for sure that refresh() in my button function does not prevent my record from being processed again, even though the status of a field in the row prevents this for other users that have an updated row.
    I hope the above makes sense…

This is how I get it, tell me if I’m wrong.

You are trying to make somthing that detects when it has just been reloaded and when it does it says somthing like “You reloaded me!”

Is that what your trying to do?

Yes, more or less. What I am really after is to make sure that the button actions take place on the most recent version of the doc - and you only know for sure it is the latest version if you have had a succesfull refresh.
That said, if the internet connection is really slow, you are still not sure that by the time your button action takes place, you are working with the most recent version of the doc, because someone else might have just updated it.
But my testing shows that with a refresh and a flag that refresh was successful, there is a better chance of working with the most recent version than without doing a refresh. The only thing I don’t know (and I can’t test right now) is if the refresh will update the current record before continuing its actions.

Hopefully this embed will work:

Hope this helps!


Thank you for making this sample doc. I think I need to modify a couple of things: fields to date/time type and update the field contents accordingly with now(), but it might work. In your sample. If I take a device off-line, it keeps on working regardless of what the status of the on-line docs are, which is not what I want.

A quick test gave me some hope this might work, because I was able to get an error message on my mobile phone while off-line. I am not sure at this point if that had to do with refresh or time functions, but I will build a new test doc and report back and share in this thread - thanks for helping out.

1 Like

After serious testing I come to the following conclusion: refresh() is not meant to be used as in the example doc above. Take the refresh() command out of the button and it still functions exactly the same. I copied the testing doc and modified the fields to time/date fields (so you can really check if the one field is newer than the other), but the result is exactly the same: refresh does exactly nothing, the checkbox value is updated because the formula in the column is triggered due to a change in the other column values, not due to refresh().

For the record: refresh is used to refresh pack data.

1 Like

I have tried come up with a solution based on these ideas (with date/time fields, but when a device is off-line, it processes everything based on the status of the fields that ‘it believes’ to be current. When the device comes online again, the table syncs. So far I have concluded that the record value that was the latest entry (regardless of the device being online or offline) prevails. This might cause some serious issues if a device is offline for a long time…