Before I explain the problem, let me set the context. I have a stored procedure which returns me paged results. So if I mentioned the page number as 1, I get the first 10 records and if the page number is 2 I get the next 10 set of records and so on.
Now in my Asp.Net page I need to show 10 items at a time and I want the pagination to be in numbered style. The same like Google pagination.
The problem now is that, since I get only 10 records at a time from the DB, the numbers don't show up. I've come across a solution at: How to use DataPager with Database Paged, however since my total number of records can run into 100's or 1000's, running the loop for so long is again a performance issue.
It would be great if you can let me know how this issue can be fixed.
Thanks in advance.
Tweak your stored procedure to add an output parameter that returns the total number of records that will be returned without pagination. You can then use that number to create your pager controls.
Related
I have a view in a very basic Drupal site -- its basic purpose is to collect data, not display it in any fancy way -- that will only show 999 items. I'm not referring to paging; I'm referring to the total number of items listed by the time you get to the last page, regardless of pagination size. I have looked at every item in the content type definition and the view and can't find anything that would cause this. I know it would be very weird, but is there some limit on the total number of items a Drupal view can handle? Is there some LIMIT 1000 clause attached to a SQL query somewhere?
Never mind people -- the problem is that the field is a text field, and not numeric (as it should be), so the items are being sorted aphabetically and not as numbers. Oops.
I'm following the example provided here:
http://msdn.microsoft.com/en-us/library/bb497936.aspx
The top half shows a stored procedure which can be used to return just the records needed, so for example if I have 100 records and want to display just 10 per page I can use the proc to tell it the maximum number of rows I want and the pageIndex to begin on. Is there a way to do the same thing without ObjectDataSource, so use a custom DataAccess layer? I'm able to get back the 10 records I want, but I don't get paging then as the GridView see only 10 coming back from the proc, is there a way to tell it I have 100, but am only displaying these 10?
As far as your DAL is concerned if the stored procedure returns 10 records, then that's all your DAL will know. Your DAL will have no way of knowing how many records are in the underlying data unless you tell it.
If you want the stored procedure to return say 10 of 100 rows and you want the DAL to know there was 100 rows in total, then you need to pass out that value separately - in an output variable perhaps?
If you are doing paging in your stored procedure, you may lose the performance you were trying to gain if you also evaluate the total number of rows affected.
It sounds as if you solution could be architected better, but we would need to better understand your requirements and what you are trying to achieve before providing specific architectural advice.
In My Database I Have 10000000 Records. In GridView First I Am Showing First 10 Records. In Order To See the Next Records User Need to Click Page Numbers ( 1,2,3,------10000). But As I'm Retrieving 10 Records for The First Time GridView Paging is not Showing.
Is There Any Way To Show Paging In ASP.NET GridView Statically ?
For so many records, I won't recommend Paging. You can show Top 20 recently added records and provide options to filter out records. A user can enter keywords. ReQuery and ReBind the GridView with this new result set.
You might also consider using PetaPoco, a Micro-ORM, which will help you fetch paged result.
With so many records, you really need to take into account the exact queries being run to pull back the data.
There are numerous ways of doing data paging ( http://beyondrelational.com/modules/2/blogs/28/posts/10434/sql-server-server-side-paging-with-rownumber-function.aspx ). However, the "best" way is dependent on the exact version of SQL Server you are running.
Essentially, the solutions boil down to you passing a page number and number of records per page through some type of query. Usually a stored procedure as the query can be quite messy.
Once there, you have an option. Either send the total record count back as an OUT parameter in your query and the result set back normally, or you send the total record count back as a column. There are definitely efficiency concerns with both options as one way requires the query to be run twice and the other requires an extra column of data which increases network traffic.
Once you have that solved then you can figure out exactly how you want the UI to work.
I am trying to refine search within the searched results based on rating.
But number of returned results is more than 1000.
So, we have to page them too, and user can sort them too based on rating.
Now, for prototyping I have stored those 1000 results in Session object.
But, is it a good idea. As there could be 1000s of queries, then Session variables would be higher.
Please suggest better / proven ways for this.
Use Viewstate instead of session if you stay on that page and not move data to another page
I would not suggest you to save 1000s records in session object, as when you have more users on your website, your server will be out of memory.
You could use a Stored Procedure to get only the number of records that you want to show in a page.
Get an idea from these links:
http://www.codeproject.com/KB/database/CustomPagingStoredProc.aspx
Stored Procedure for Custom Paging
I am encountering a performance problem in the development of current UI. The problem, I suppose, is however general.
I have a page with a simple asp.net grid. Grid will display data from a table based on certain search criteria. Moreover, grid has fixed page size (say 10). There is pager at the bottom which can be used to navigate b/w pages. On the back end, whenever search button is pressed a stored procedure is called which returns the desired data.
Stored procedure has parameters like currentpageIndex, pagesize, other search criteria, etc. Here is a pseudo code for sp:
-- SP begins
-- calculate the page index range to return required using current page index and page size
-- query the table in a CTE and do all filtering. Also calculate row numbers so that
-- correct record range can be returned.
-- use the cte to return the correct record based on the row number calculated in CTE
-- SP ends
I have following problems/queries in this approach
When Db table size is large (say 10 million records), performance degrades and this approach becomes impractical.
Is using table variable or a temporary table more useful?
Is there any other efficient way to get paged data from database?
Hi Dan, the article provided a new insight for calculation of total rows. Really helpful. Thanks.
But still is there better way than using CTE when data is large?
Update: I have found few other performant approaches for efficiently getting paged records.
There's a good article on SqlServerCentral called SQL Server 2005 Paging – The Holy Grail that shows a few techniques for server-side paging. You will need to register to view it, though.
I know for really large result sets then software like Google will simply estimate how many rows will be returned, bypassing the need to get a count of all the rows returned.
Sorry, if I can't give more help.