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.

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?

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.