Editable Grid - Paging controlling number of records displayed per page

I recommend against this design approach in almost all cases.  The reason is that even if you manually implement paging in your data that you load to show on the current editable grid "page", it gets VERY complicated to manage *updated* data when the paging controls are used.

Usually I will strongly recommend that if you need a PAGED grid, then you use a READ ONLY grid and add a control onto each row to open it SEPARATELY for editing (like in a small section below the grid), where the user can complete and SAVE edits prior to moving on to a different entry.

I recommend against this design approach in almost all cases.  The reason is that even if you manually implement paging in your data that you load to show on the current editable grid "page", it gets VERY complicated to manage *updated* data when the paging controls are used.

Usually I will strongly recommend that if you need a PAGED grid, then you use a READ ONLY grid and add a control onto each row to open it SEPARATELY for editing (like in a small section below the grid), where the user can complete and SAVE edits prior to moving on to a different entry.

Yes Mike Schmitt  agree with you, it is very complicate to handle and update the data. unless any rare requirement 

Mike Schmitt could you please provide an example on how to implement this option?

1) show your data in a read-only grid

2) add an icon-size column which contains an "edit" icon (for instance), which is a link

3) clicking on the "edit" icon copies that row's data temporarily into a local variable, and this is displayed in a section below the grid, in editable fields (also the "edit" icons in the original grid are disabled)

4) after edits are completed and the user clicks something (in that local section) to save their edits, the data is populated back to the database and the section closes, and links in the original grid become active again

Thank you, I know how to do up to step 2, when you say copies the data temporarily where are you doing that exactly?
Is there any document or code that I can refer to?

Maria said:

when you say copies the data temporarily where are you doing that exactly?

The "where" is the local variable I also mentioned.  To expand on that, I mean that you would declare a local variable (nominally at the top of the form with most other local variables you're using) that would initially be blank, but when you click a row's edit icon, you call a dynamic link that saves the data of the current row into that local variable (therefore ending up with it populated with a dictionary of the current row's data).  This local variable would be what the "edit section" fields reference (and target for the saving of changes), and then when the user Saves, you would write that local variable's updated value back to the DB by some means.

Maria said:

Is there any document or code that I can refer to?

There might be a recipe for something like this in the Appian Recipes if you dig, but I don't happen to know off the top of my head.

Mike Schmitt , I know you mentioned this earlier but could you explain a bit more why that updated values would be more complicated to manage? isn't each item being "saved" when it is inputted to that specific row at that same time ? just like the regular functionality of the editable grid?

This only holds true if the entire set of original row values is being loaded into local variable memory on the interface and held there (plus or minus edits from the user) until "save" time.  However often when we have data we need to page over, it means our data set is so large that loading it all on the form would either run into performance implications, or be impossible overall.

Thus the standard style of loading for a paging grid is to query only paged sets (as determined by the paging controls) - this is what i consider as "true" paging, whereas the working solution above (loading all data but only displaying chunks of it at a time) is more of a "superficial" version of paging.  In a "true" paging scenario, the local value would be essentially unloaded and replaced with the next "page" every time the page is switched, meaning that edits would need to somehow be taken care of before that, which is why I say it's tricky.

If the superficial approach will work for you (and you've already handled issues like field-by-field validations and requiredness settings, before the user changes the page each time, which is another hurdle), then it might be a feasible solution for you.