It's strange, it shouldn't happens … especially within a rangesum() which treats non-numeric values or NULL as zero so that if there are no numeric parameter the result should be zero, too.
This means that at least one of the parameters is invalid in the given context and prevent a correct working of the entire rangesum() so that they returned NULL (the hyphen is just a replace-char for NULL).
It's difficult to say what's causing this effect … In general I would check if there are NULL's (real NULL's, empty values, spaces, any other kind of invalid values) within the field - I assume it's rather not relevant for this example but it might cause problems and/or erroneous respectively unexpected results.
This means you need to consider strategies how to handle them - this could be the replace of them per NULL variables/mapping or any other kind of replacing (for example with a string like 'Null' or ''NV' or maybe just with 0) or to exclude them from your further calculations (maybe within a set analysis).
More likely seems to be that the pick-index failed in any way - especially if there is more than a single dimension in the table and/or there are conditions applied on the dimensions and/or there are further selections within the application. In all these cases need the rowno(total) and the count() separately checked if they return the expected values. If not it could become difficult to adjust them maybe further set analysis and/or aggr() could be used - but easier would be to simplify the objects/logics.
Another thought goes to the formatting of the fieldvalues - if they are different to the default number-format and/or this has a comma as decimal-delimiter it's troublesome. Therefore I suggest to check this, too and to apply some of the following approaches:
alt(num(floor(num#(keepchar(trim([Column A]), '0123456789,.'), 'ConvertFormat')), 'OutPutFormat'), 0)
to ensure a certain format/data-type.
- Marcus
