How to handle million of record in gridview asp.net

Question

1.75/5 (4 votes)

See more:

SQL-Server-2005

, +

I want to enable paging in gried view in asp.But numbers of record is more million so which will be best approach to handle paging in such situation.Please give me suggestion as soon as possible.Please.

Posted 21-Aug-12 7:30am

Himanshu Yadav

Add a Solution

Comments

Member 9511618 6-Sep-13 1:06am

How to handle million of record in gridview asp.net give me c# code please

ridoy 21-Aug-12 13:42pm

more specific please

2 solutions

Solution 3

Paging is fine but when it comes to millions of records, be sure to fetch the required subset of data only.

You can provide the record number start with and the maximum records to retrieve from that starting point. This enables you to retrieve only a subset of records from the datasource based on the current page index. All you need is to keep track of the the current record index.

You can store the record index in viewstate or in hidden fields run at = server.

So, while you first load, set the pageindex to 0 and say you display 20 records.
When the next is clicked, update the page index (pageindex++).
Say when you click 8th page, set the page index to 8 and so on.

Now, when you fetch the record from database, pull the data for pageindex 8.
To get the record number,
fromrecord = pageindex*displayrecordno
torecord = fromrecord+displayrecordno

In the e.g. displayrecordno=20

Hope this helps.
cheers

Posted 21-Aug-12 7:52am

Sandip.Nascar

Comments

Himanshu Yadav 23-Aug-12 2:59am

Hi i am agree with but the problem is that it was asked in an interview they told me to apply best approach I told them it can be attain by three process
(1.) storing record in view state and then we can fetch record from it but they raise two question
(a)its makes yr page heavier
(b)Pages number will not be displayed in grid view ( as i told to Maintain from some global variable by storing current page index and next page index.... )
2. By storing in Catche but in this case i will face problem (b) of first

3.By sql stored procedure by passing current index and next index as input parameter and fetch only that much of record.

But they were not satisfied so i need help please help me out

Sandip.Nascar 23-Aug-12 4:00am

First of all, viewstate indeed will slow down the performance. Think about the number of data the view state will store and all that counts to client-server kb transfer. Its huge.

Second is where to store the current index and next index. Definitely not in cache. You can use hidden fields make it run t="server" to store those values.
Remember one thing, cache is not an alternative to store persistent data. It is used for separate purpose.

Hope this clears you confusion.
cheers

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Sergey Alexandrovich Kryukov · Accepted Answer · 2012-08-21T07:51:00

This is not a valid formulation of the problem. Even with the very best and fasted paging you can possibly achieve, what would be the number of items on a page? 20, 50, 100 at best, otherwise it's not well manageable. A million means the user needs to click "page down" at least some 5,000 times just to reach the middle of the data set. Totally not realistic.

So, the whole idea of "paging" cannot save you from prohibitively overwhelming volumes of data. You need something else. For example, you can create two-step hierarchy by some key (very usually, it's the alphabetical order with listing by first letter). Multi-level hierarchy (in practice, hardly more than 2 or 3 levels) could be presented as the lists of items with selection, so the selection acts like a sub-query, re-populating items on the right of the given control. Also, you can give the user the estimate of a total records to be shown on a single request and suggest to narrow down the query. You can assist the user based on the query results, but it could be a smart technique, needs a lot of thinking.

Main thing here is: there is no one universal recipe for best solution, because it all should essentially depend on the structure of your data and the purpose of the UI in question and the whole application. You can only get different ideas and adopt them for your case. For some more food for thought, try to look for good massive data applications on the Web to see how they present queries, results and navigation.

—SA