I survey that is using a submission url with an existing feature service and I am trying to limit a repeat count to 1, but avoid the _count field being included in the schema. I've read that this is possible by referencing another field in the repeat_count column. I have attempted this, but it seems to add the {repeat}_count field to the schema regardless of what I enter in the repeat_count column of the repeat question. Does anyone have an example form that limits the repeat count of a repeat question, but does not require the _count field to be added to the schema?
Hello @JamesTedrick
I have the same difficulty in a workflow in Survey123 Connect, with a HANA db feature service.
Do you have an alternative solution (Workaround) to be able to overcome this difficulty?
I have had many issues with repeat_count, esp when nested.
So instead I use a count(fieldinrepeat) and set a constraint on it. Only bummer is they have to go one past for it to trigger, then delete that last one. It works fine though.
Works much better, esp for large repeats with lots of fields. Hope that helps.
Hi Doug - can you proved a more detailed example? I'm not 100% clear on what you mean. It sounds super useful.
Couple of ways depending on what you are trying to do but the key is the same.
Inside my repeat I have a field that counts up some other field in my repeat.
I have a field the inherits the key from the Parent so I just count that.. Or just make a dummy field.
Field Calc
RecKey ${LineKey}
Then do a running total inside the repeat. Using once so that it grows as you add, and it does not recalc on me.
Then you can add a constraint right here to make sure they do not go to far. Note it does let them create 51 but they cannot save it. In one form I even set text to tell them right away they went too far.
Field Calc Constraint
PointNum once(count(${RecKey})) .<=50
If you want to make sure they went far enough then you need to move it outside the repeat. In my case I want them to do exactly 50.
Field Calc Constraint
PointsCompleted count(${RecKey}) .=50
I actually just do the last option since it will catch both. But technically they could then make like 100 and have to delete. But in our case that is not really an issue, they usually just miss one.
I hope that makes more sense, harder to type then I thought. But in the end you are just counting and then using a constraint.
Ah interesting. Could you, in theory, use this to force users to submit at least one repeat record?
I think so. But a required in the repeat should do the same thing.
Doug,
That is a creative workaround. I think in my case I'd prefer to avoid the potential for confusion with the users having to delete repeats. The whole repeat portion of the form seems to be the most difficult for our users to grasp. Adding nested repeats is even more confusing to them. I ended up using a hosted feature service that has the schema Survey123 is expecting with the _count fields where necessary. Then, I use FME to sync the data from the hosted data store to my Oracle database nightly, ignoring the _count field in the hosted service.
Brandon Jameson: Don't be difficult.
Carlos Krefft: Typical user...
Sorry, I have an ex-coworker with the same name as you and I thought you where him. I thought it would be funny to troll him. My apologies.