nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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

Najděte více příspěvků označených jako

Accepted answers

All comments

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:

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.
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?
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}

Připojte se ke konverzaci

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Jste tu noví? Zaregistrujte si bezplatný účet.

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.