The cause is that there are no values available for the field. If this happens the set analysis condition is just ignored and therefore the expression returned the results for the whole dataset. I agree that's from a user point of view not the expected behaviour. I assume that there are technically reasons because the set analysis logic based on the system- and state-tables and the normally returning TRUE or FALSE couldn't be assigned to NULL respectively to NOTHING. A technically solution for it might be to implement a further loop which checked each set analysis statement - but the performance impact would be probably quite huge. Therefore I believe it is like it is ...
An alternatively might be to ensure that there is always a field-value maybe with something like this:
concatenate(YourTable) load ' ' as YourField autogenerate 1;
Probably there are more elegant ways to implement such things and of course it has some side-effects especially if it's applied to a larger amount of fields.
Beside this you could try to bypass such cases by applying an indirect set analysis, maybe with something like this:
count({<PatientID = {"=OverdueForSecondDose='Yes'"}>}DISTINCT PatientID)
but it's not really better as your if-approach because it's mostly the same just the syntax is different.
In both above mentioned workarounds you need to know which fields have any values or not to apply any of these logics.
A more robust alternatively could be to adjust the datamodel to switch from a more or less crosstable-structure to a stream-data structure, means changing something from:
ID First Second Third
1 yes no yes
to something like:
ID Category Value
1 First yes
1 Second no
1 Third yes
and the risk to run in such an issue should be massively reduced.
- Marcus
.png "Former Employee"){kind=icon}
