Morning all, Has anyone found a 'nice' way round this issue o

Morning all,

Has anyone found a 'nice' way round this issue on a paging grid in Appian 7.8:

The dataset is expression backed via a webservice and often contains data that has a mix of 1 type (e.g. Boolean) and nulls.

When attempting to sort on the field an error is generated:

"The sort field must be a consistent type. Found two different types: 26 and 3, for sort expression <name>"
Type 26 = Boolean
Type 3 = Null.

Formatting the data in the a!textGridColumn has no effect as the sort is performed using the raw data from the expression, and we would like to avoid having to convert everything to text in the webservice and then back to the required dataType

Thanks in advance,

Gareth

OriginalPostID-157072

OriginalPostID-157072

  Discussion posts and replies are publicly visible

  • 0
    Certified Lead Developer
    Hi Gareth, so your data is returning the word "Null" or at least an empty string if it's saying type 3. If your webservice returned an actual null value then the paging grid would be able to handle the sorting.
    So the issue is with your data, somewhere it needs correctly type matching before Appian should be asked to put it in a paging grid. A boolean type with a string value obviously makes no sense..... nor does having a null boolean but that's a whole different topic!
  • Hiya Tim,

    The field is returning a value of null - as opposed to "null" or "".
    Use case in this instance is to report whether an event has been completed.
    Not all eventTypes have this field - hence the null and a yes / no is not appropriate.

    However - this is not confined to Boolean fields. We have encountered it with a mix of number(interger) and null and also number(decimal) and null - where there has been no figure entered. Both of these cases we worked round the issue by converting all numbers to strings in the web service, and then back again in the SAIL - which is not ideal, but does the job.
  • 0
    Certified Lead Developer
    Hi Gareth, Type 3 is a string so it's not a true null. The following reproduces your error if you use an empty string or the word null but if you use the null system value it works fine. Somewhere your data is wrong....

    =load(
    local!var: {
    {id: 1, value: true},
    {id: 2, value: false},
    {id: 3, value: null}, /* replace with "" */
    {id: 4, value: true},
    {id: 5, value: false}
    },
    local!pagingInfo: topagingInfo(1,-1),
    with(
    local!data: todatasubset(local!var, local!pagingInfo),
    a!gridField(
    value: local!pagingInfo,
    saveInto: local!pagingInfo,
    totalCount: 5,
    columns: {
    a!gridTextColumn(
    label: "Field 1",
    field: "value",
    data: local!data.data.value
    )
    }
    )
    )
    )
  • Thanks Tim - Every test I have run on the data is returning true null values - except when used in the dataset, when the nulls are being returned as type 3 (text).

    I suspect the reason for this is that the data is not explicitly typed - the value array is built from jsontodictionary() and that the function is assigning all nulls a type of 3 - I have tested this with a json string with a mix boolean, num(int), num(dec), date dateTime and each element with a value is getting correctly typed, whereas every null is assigned a type 3 no matter the datatype the column has been assigned.

    As the json is dynamic and can't be typed, pending a fix to the rule, it looks as though I will have to resort to the backup of sending all values through as quoted text and then convert it in Appian.

    Thanks for your help!
  • 0
    Certified Lead Developer
    The old jsonutilities plugin had this bug as well until I updated the version that you use. If you're using the PS jsontodictionary() plugin consider modifying the source to fix it. Also on 7.8 you have access to a!fromJson() - does this behave in the same way?
  • Tim,

    You, sir, are a scholar and a gentleman!

    The bug is still present in the PS jsontodictionary() plugin but a!fromJson has a value of null equate to type 57... which can be sorted normally.