Getting StartIndex must not be greater than TotalCount issue

We see this error regularly when filters are changed which reduces the data set size, after paging has been used.  For instance, if you have a grid with paging set to 10 rows:

- Current filters return 30 items total, grid shows 1-10
- The user pages to items 11-20
- The user changes filters, which reduces the result set to 8 items
- An error occurs because paging startIndex remains at 11, but there are only 8 items in the new data set

In that situation, any time the data set can be reduced by filters/etc, the resolution is to manually reset paging startIndex to 1 when any filters are by utilizing a!save().

Appian

Hi Chris
Sorry for the delay in response. But how we can update startindex to 1 because we are using fv!paginginfo as the paging parameter which is calculated automatically by the grid. When i try to update the startindex to fv!paginginfo, its showing fv!paginginfo as improperly scoped variable. Any suggestion will be helpful

Hi Chris
Sorry for the delay in response. But how we can update startindex to 1 because we are using fv!paginginfo as the paging parameter which is calculated automatically by the grid. When i try to update the startindex to fv!paginginfo, its showing fv!paginginfo as improperly scoped variable. Any suggestion will be helpful

If you are using custom fields for your filters, which it looks like you are doing with a search text box, you can't rely on fv!pagingInfo and will instead have to manage the paging with a local variable and therefore reset it any time a user adds a filter value.

Hi Tim 

If thats the case, can you please let me know how can the paging achieved dynamically? Do we have to build paging icons separately ( I mean the next page and last page icons). Cause without it, I dont think its possible to achieve it. Would be really helpful if there are any suggestions for this

Sarathkumar R said:

Do we have to build paging icons separately

That's not what "manage the paging with a local variable" means at all.

It just means declare a local variable prior to the query i.e. "local!pagingInfo: a!pagingInfo(1, 10),", which is then fed into the query instead of fv!pagingInfo (in such cases I prefer to query in a separate local variable from the grid itself but I believe either way should work); then anytime the user-controllable filtering is changed, save "1" back into local!pagingInfo.startIndex.

Here's an example with utilizing refresh variables on pagingInfo and data.  Paste into a new interface, page over to 11-15, then add any text into the Search box:

a!localVariables(
  local!columnValues: {"id","userName","data"},
  local!columnDisplay: {"ID","Name","Data"},
  local!search,
  local!pagingInfo: a!refreshVariable(
    value: a!pagingInfo(startIndex: 1,batchSize: 10,sort: a!sortInfo(field: "id",ascending: false)),
    refreshOnVarChange: {local!search}
  ),
  local!data: a!refreshVariable(
    value: todatasubset(
      a!forEach(
        items: 1+enumerate(if(rule!APN_isEmpty(local!search),15,7)),
        expression: {
          id: fv!index,
          userName: concat("Name",fv!index),
          data: concat("Data",fv!index)
        }
      )
    ),
    refreshOnVarChange: {local!search}
  ),
  {
    a!textField(
      label: "Search",
      value: local!search,
      saveInto: local!search,
    ),
    a!gridField(
      data: local!data.data,
      pagingSaveInto: local!pagingInfo,
      columns: {
        a!forEach(
          items: local!columnValues,
          expression: a!gridColumn(
            label: displayvalue(fv!item,local!columnValues,local!columnDisplay,""),
            value: property(fv!row,fv!item,null)
          )
        )
      }
    )
  }
)