Repeatable calculation occasionally not executing

[Andy_CS]

I have a calculation type question (ccTotalTrees) inside a S123 repeatable that returns a value of 1 or an integer from another response (crUninfestedTrees, which cannot be left blank) depending on the survey type.

For one user the calculation is not always executing, when it doesn't the field value is set to null. It's only happening for one user out of about 60 and I cannot figure out why. They are using the same, current, S123 version as other users.

The calculation mode is set to always.

Just wondering if anyone has any ideas, as I am stumped. I was wondering if the problem was caused by them switching survey types from infested to uninfested before submitting.

Edited: there is no relevancy on ccInfestedTrees

type	name	relevant	calculation
select_one SurveyType	prSurveyType
begin repeat	rsTrees
integer	crUninfestedTrees	${prSurveyType}='uninfested'
calculate	ccInfestedTrees		if(selected(${prSurveyType},'infested'),1,0)
calculate	ccTotalTrees		if(selected(${prSurveyType},'infested'),1,${crUninfestedTrees})
end repeat	rsTrees

[DougBrowning]

I wrote an answer then realized it is not what I thought.  Not sure the outcome you want here.  You are counting uninfested but if they see any infested at all then ccTotalTrees gets a 1?  I would think you would count both and have two diff totals then a master total.  Sorry not sure the workflow here.

If it is a total or 1 thing I would just remove the relevant from ccInfestedTrees.  You always want that to have a value here - a 1 or a 0.  Relevant can fire in the wrong order which gives ccInfestedTrees a value of "" which then breaks TotalTrees.  If you really want ccInfestedTrees to be blank if no infested trees I would just do if(selected(${prSurveyType},'infested'),1,"")  But to me having a zero makes more sense.

I was assuming you wanted a sum across all repeats.  That would be a sum(total) outside of the repeat.

Sorry but hard to follow but try that.

[abureaux]

To add to what DougBrowning suggested, I would also suggest:

• Making rsTrees relevant statement ${prSurveyType}!='' so you can only start collecting data after a selection has been made.
• Removing the relevant statement entirely from ccInfestedTrees since calculates are intrinsically hidden, and having a null values for a calculate should be done via logic statements.

[Andy_CS]

@DougBrowning, @abureaux . Thank you for your replies. I've tried to clear up the workflow below, apologies for the length. I have also made an error in my original post, ccInfestedTrees has no relevancy - I've edited to correct.

Workflow: All trees on a site are surveyed for infestation, information about the site is recorded outside of the repeatable. A survey can be used to capture multiple trees within a site via the repeatable section but they all have to either be infested or uninfested (prSurveyType).

Trees are captured within the repeatable, each repeat is either:

• a single infested tree, ccInfestedTrees is calculated to 1 automatically.
• multiple uninfested trees, surveyors enter a response into ccUninfestedTrees

ccTrees takes the value from ccInfestedTrees if prSurveyType=infested and from ccUninfestedTrees if prSurveyType=uninfested. This response is used to drive a dashboard counter that sums trees across all repeatables for all surveys.

The calculation in ccInfestedTrees is there to handle nulls for the calculation in ccTrees. It sets ccInfestedTrees to 0 if the survey type is uninfested. ccUnifested trees cannot be null as the response is required

For some reason the calculation in ccTrees does not always execute, and I get a null value which throws off the counter on the dashboard. The weird thing is the problem only occurs for one user out of ~60.

@abureaux- The relevancy ${prSurveyType}!='' exists on on the group containing the repeatable. The form is using pages, users only see the page containing the repeatable section once they make a selection in prSurveyType.

[abureaux]

Honestly, I'm not wrapping my head around this: "All trees on a site are surveyed for infestation... A survey can be used to capture multiple trees within a site ... but they all have to either be infested or uninfested..." How do you survey a site with more than one tree (E.g., a site has two trees, one infested and one uninfested)?

But I digress. Everything appears okay, but that is only with making a few assumptions. So, so avoid any assumptions...

• When you say ccTrees, you actually meant ccTotalTrees (based on your example above)?
• crUninfestedTrees is a required field?
  
• rsTrees is a required field?
  

Right now, this is how I assume the form is set up (with the exception of line 7):

If my assumptions are correct, then I don't see an issue with the form pre se. Maybe try tossing in line 7 and see how it goes?

If it is just a single user having issues and the form appears to work as intended, there are really only a few possibilities:

1. User error. This is why I ask above if fields are required. If they leave something blank, that will result in null. Adding line 7 should also alert the user before a form gets sent off that there is an issue. In that case, they can save to drafts and you can inspect their submission at a later time.
2. Hardware issues. Are they using a different device than other users? Is their device fully updated? And are you testing for this? (I don't trust my users to report accurately on what they use, so I have calculates in all my forms to collect metadata on user's hardware). Assuming they use the same hardware as other users, have them check for updates and confirm they are all installed. If they are using different hardware, can they switch?
3. There is actually a bug somewhere. While unlikely, this isn't impossible. I can think of at least one bug off-hand that affects maybe 1 in a hundred users (not related to your issue -- what I am thinking of is web hook related)

Starting with the more likely #1 and #2 would be best.

[Andy_CS]

Thanks for taking the time to look at this. All of your assumptions are correct and the form looks as your one above, with the exception of your line 7.

I do capture hardware metadata and the problem user is one of two using Android 9.0, everyone else is iOS or Android 14.0+. Their device is relatively old too so hardware could be the issue. Their S123 app is up to date, I'll ask them to check operating system. Switching device will not be possible.

User error shouldn't be a problem as I've got required fields set up where needed but I will add your line 7 to test.

We're not losing any data from this problem, it's only my dashboard that is affected so I'll try and handle it there - it does have me stumped though!

With regard to the survey design: If a site has infested and uninfested trees we require separate surveys to capture them. The repeatables are either all infested or all uninfested within a single survey. We have previously allowed surveyors to capture both types within the same survey but we ended up with more errors in data capture.

[abureaux]

Ya, this does seem odd. May be an unfortunate case of hardware-related issues, which means there isn't much we can do short of replacing the defective hardware.

It only just occurred to me that I didn't include the row count in my screen-cap, so I am making you manually count rows. Sorry about that! But I am of course referring to ${ccTotalTreesTest}

[Andy_CS]

Okay, I've done some testing and can replicate the issue.

1. Select 'uninfested' in prSurveyType

2. Create a new repeat in rsTrees, enter a number into crUninfestedTrees

3. Create a second repeat, do not enter a number into crUninfested trees.

4. Submit the survey, this will trigger the required field warning for crUninfestedTrees in the second repeat

5. Enter a value into crUninfested trees to validate the second repeat

6.Submit

The calculation in ccTotalTrees will not execute for the second repeatable and a null value will be returned. So it looks like the calculation is not executing after the required field warning has triggered. The same issue occurs if a third repeatable is added instead of submitting at step 4.

If ccTotalTrees is set to required the requirement warning is triggered at step 6. Pressing submit a second time executes the calculation. I think this would confuse our surveyors.

I'm not sure that this behaviour is expected, I'll have a re-read of the documentation and try support if needed.

@abureauxmy understanding was that the 'always' calculation mode would solve this but as per your comment in this thread maybe not?

Edited: formatting

[abureaux]

Yes, my comment in that thread is valid. And I forgot about one scenario... I tend to always build around this one issue, so can forget it's a thing... While in a repeat, entering a value is only half the storey. You also need to "activate" that field. Try the same process, but press Enter at the end. I'd bet the calculation works.

If pressing "Enter" works, add the "numbers" appearance to that integer field. When a value is entered via an integer/decimal field with the numbers appearance, the mere act of entering a value also validates that value (e.g., simulates pressing "Enter"). When it comes to repeats, I always try and use fields that "authenticate" themselves, otherwise you risk calculates not firing properly like you described. Basically, anything that isn't a plain text field (regardless of the data type) counts as a self-validating field.

EDIT: And just because we are on the topic, you can also cycle through a repeat to activate calculates that didn't work correctly the first time. The act of cycling through the repeat (i.e., going from one repeat record to another) "activates" all the fields in that record, so a calculate that didn't work correctly the first time will work properly the second time. This is very noticeable when you create "summary" sections for repeats. If you enter data and press the "new repeat record" button before a field "validates", your summary section will have blank spaces. But then back-tracking through your repeat will activate those calculates. As I mentioned in the thread @Andy_CS linked, calculates only work for the active repeat record, thus ignoring calculationMode=always.