Constraint allows blank values to go through on Integers

[DougBrowning]

I have a constraint on an Integer field where it must be 0 if another field is No and > 0 if Yes.

if(${FlowPresent}="No",${ThalwegDepthCM} = 0,${ThalwegDepthCM} > 0)

(note I had to write out the field name since .>0 did not work)

If I pick No then enter a value that is not 0 then the constraint fires and stops me.  But if I leave the field totally blank then it lets it go through.

Is this a bug?

I also tried testing string length and that lets it go also.

if(${FlowPresent}="No",${ThalwegDepthCM} = 0 and string-length(${ThalwegDepthCM}) != 0,${ThalwegDepthCM} > 0)

and tried string-length(${ThalwegDepthCM}) > 0

How can I fix this?  Note I cannot use relevant since the users sometimes do not do the form in order.

Thanks

[Jim-Moore]

Hi @DougBrowning 

As @JamesTedrick mentions here, making an integer field required means it cannot be blank (NaN).

In your survey, would it be suitable to make the ThalwegDepthCM question required, conditional on the FlowPresent question being answered? For example, use string-length(${FlowPresent}) > 0 in the required column and then use your first constraint expression to enforce the 0 or > 0 value, i.e. if(${FlowPresent}="No",${ThalwegDepthCM} = 0,${ThalwegDepthCM} > 0)

Cheers,

Jim

[DougBrowning]

I have a default I need on Flow so that will not work.

I also tried a constraint of 

if(${FlowPresent}="No",${ThalwegDepthCM} = 0 and ${ThalwegDepthCM} != 'NaN',${ThalwegDepthCM} > 0)

and if(${FlowPresent}="No",${ThalwegDepthCM} = 0 and ${ThalwegDepthCM} != NaN,${ThalwegDepthCM} > 0)

But both of those still let blank go through.  I have had this issue before I think and never solved it.  string length also seems to not work in a constraint if it is the field you are on.

thanks

[JamesTedrick]

Hi Doug,

Can you provide more detail?  Based on your description, I have created a basic form that attempts to replicate the condition and it appears the constraint operates successfully.  

Also, can you check which version fo Survey123 Connect/Survey123 you are using - the issue with . not working was introduced in a beta release; the current-most beta available on EAC has this resolved.

[DougBrowning]

I am using 3.11 right now.  I just tried the form you posted and it is letting blank go through.

thanks

[JamesTedrick]

I also developed the form with 3.11.  Given the default I set, I would expect the answer would go through when 'No' is clicked - the condition was if No is clicked, the value must be 0.  Given that you mentioned that you had a default value, I used that as the default.

[DougBrowning]

Ok I am confused then.  Blank is not 0 so why is it not giving an error?  I am trying to say it must be 0.   Is it considering the field not filled out yet maybe?

Also why does string-length not catch it either?  The weird thing is string-length(.) > 0 and string-length(.) != 0 both allow a blank.  But when I try string-length(.) = 0 and put in a value it does fire the error.  string-length(.) > 1 also does make me add at least 2 numbers.  I have tried using string-length(.) for blank a number of times over the years and it never seems to go.  . != '' does not work either.

So it seems that blank is being treated as a special case?  

Sorry not sure what I am missing here.  Thanks

[JamesTedrick · Accepted solution]

Hi Doug,

If a question has a default value, it is not blank.  As I mentioned, the form sample I provided has a default value that met the requirement when 'No' is selected. A blank value indicates that a question has not been answered and calculations will not fire.  If a question must be answered, you need to set the 'required' value appropriately (either 'yes' or a condition)

[DougBrowning]

This field would not have a default value since it was coming from a relevant.  But in the new beta it looks like defaults are now working when a relevant field appears?  I was trying to test but it looks like my pulldata is no longer working in the 3.12 beta.  I will test it some more and post that separate.

I would still think a constraint should check a blank but good to know that is how 123 sees it.

Thanks