I have devised a way perform several things I'm sure that many Telerik developers have wanted to be able to do, and seperately there are plenty of posts around these forums that assist in one or the other. I've tried to use many of them myself, but ended up with a completely different solution, which I will descript how to do below:
I have a web application with dozens of screens, with dozens of grids on them, each with dozens of fields that require filtering. Some of these screens return thousands of rows, and I was relying on client side filtering to make the web app easier to find what the user wanted.
I saw posts on how to use custom paging, but if you modify your code to return, say, only 50 rows per page and you are performing the paging in your query/stored procedure based on page number * page size, the client side filtering will only work on those 50 rows returned - even if there were matches on other pages that did not get returned in your result set.
Also, I wanted to persist my filters across pages, so that if I left that page and then later returned to it, my filters would still be intact and displayed. I could not get any of the samples I found using google to work.
With persistent filtering in place, using standard paging so I could filter across my entire dataset (not just the set of pages that were returned via custom paging), with another small tweak I have been able to 'Turbo Charge' the performance of many of my screens. I was able to take a screen that took 20 seconds to load and reduce it down to about 2 seconds. The initial load (with no filtering in place) still takes 20 seconds, but once a filter is in place, it screams.
I will detail how this can be done as best I can as this is my first post to these forums. I'm sure there are probably better ways to achieve what I have, but I'll post how I did it here anyway so any other people who want to do the same will have a framework to start from and improve upon.
The main 'trick' I used to boost the performance across an entire dataset was to pass a slightly modified form of the combined radgrid filterexpression to my sql stored procedure and make it part of my where clause, so that the procedure itself would tie it's results directly to the filters the user wanted and only return rows that matched the filters, which results in a HUGE performance boost when you are dealing with large recordsets because the filtering was done on the server side instead of the client side.
To achieve truly persistent filtering, first, turn off linq expressions in the page load sub and perform your first save and load of the persisted filters. Note for multiple different pages you are implementing this on, the UniqueKeyForThisPageAndGrid will need to be, of course, unique.
Set up the session storage provider in your code behind page:
Add this new sub in your page (make sure to use your unique column names, and your radgrid name)
In the radgrid_DataBinding function, collect the filters as follows:
Now, in the radgrid ItemCommand sub, check for filter operations and save the state of the filters and such. Keep in mind, there is a unique key in the code below that you must set for each and every different grid, on each and every different page you want to persist seperately.
To Retain the saved Page number you were on, this function is needed (and called from the page load). If you have multiple grids on the same page, use this function to check and set each one. Remember to use your page name and your grid name followed by "PageIndex", not the hardcoded text below:
You will also need to implement these:
Now, you need to ensure that the datasource your grid is using allows for the special sql expression as a parameter. In this example code, I have used session variables so that it also persists across pages.
In your asp page, add the radpersistencemanager for your grid(s):
In your asp page for the <ASP:SqlDataSourceID> being used by your radgrid, add:
Also Addas a parameter to your stored procedure.
And finally, the stored procedure will get some rework done to it. You can't pass a piece of a where clause to a procedure and expect it to work. What you need to do is convert your sql code to a large string, then add the passed in piece of the where clause to it, and execute the string. There are a couple things to do to the procedure first. Inside your stored procedure, add these lines above your select statement:
These lines declare a needed variable and replace the parameters in the string with left and right quotes to surround your LIKE clauses.
Next, since your database schema table fields may not be named exactly like the UniqueID's you specified in your radgrid, we need to replace them with their actual table field counterparts (remember to use the table qualifiers like a. and b. etc if needed by your actual query)
Now, you need to convert your original query into a string. Take care to modify any parameters that were passed in to still be used properly by building them into the string similarly as we do below with our new @clause variable.
--and now add your passed in piece of the where clause and execute the code:
And that's it. I know this mish mash of code in this post might be a bit much to chew on, but I wanted to share my success with persistent filtering and turbo filtered results on large datasets. Feel free to try and incorporate what I have been able to achieve in your own code. Even if you choose NOT to use the sql modifications here, this is a really neat way to persist all the filtered columns across pages.