We have developed Asp.net web application. and we are using asp.net gridview to display the records and edit.
here we have 5000 rows and 23 columns in single grid. it is taking long time for binding. our client refuse the pagination option. how to make the binding faster with 5000 to 7000 records.
Please Advise.
Thanks
Mayil.M
Where is your data come from? Is it database or other external resource?
You can use caching so you don't load the whole dataset from the external resource but from the memory. Please note this solution will not work if your data changes often.
Another approach would be to use some kind of partial loading mechanism using for example Ajax. This will however require changing approach as I am not sure the grid view control supports this. You would have to create custom control and then make sequential requests (using for example Ajax) for smaller chunks (eg. 200 records) of data and display them. Eventually you will have complete set but the data will be available faster.
Finally you can combine both, to make it even faster.
You should implement your own paging mechanism. The problem is that DataBind retrieves all 7000 records (although only i.e. 20 is displayed/rendered). Create for example a stored procedure that will fetch only selected range of records (if you are on Page 2 you need to display only record id > 20 and <= 40 - considering that your pagesize is 20). Use SQL server CTE to get the row number (on SQL Server side) and features like BETWEEN. This stored procedure would return only those records which you really need to. Then change your grid view to get the data from this stored procedure.
You can load data on scroll like facebook wall.
Related
Have drop-down menu which fills 4 datagridviews based on the branch selected or when the start button is pressed loops through 80 branches.
4 sql server procs, 1 per datagridview, unique sql table, read access, only.
Need to access multiple copies, single url.
Database retrieval time = # of copies run (single asp.net websites over single url called multiple times) * database runtime.
So if it takes 30 seconds for data retrieval, running 3 copies takes 90 seconds and seems to fragment the data or timeout..
I'm using nolocks so there isn't deadlock.
But I need to optimize this.
Should I create one web service and will this solve the problem of hitting the database only one time instead of 1x per single url hit.
Thank you.
David
Thank you, the timer was taking over and performing differently on the server than on my local. Also the UI, timer, and Database were out of synch. So adding a thread.sleep helped. Adding a longer interval on the timer, helped. Also putting all the database calls together, instead of 1 connection per database call helped. Now it runs all the same time.
The main takeaway I think is that the timer and the Thread.Sleep was the main thing.
I also had a UI button - which I added some code so that once it's pushed, if you keep pushing it, it doesn't do anything.
Thank you to everyone that posted answer..
Well, this will come down to not really the numbers of records pulled, but that if you are executing multiple SQL statements over and over.
I mean, to fill 4 gv's with 4 queries? That's going to be quite much instant assuming the record set size for each grid is say in the 100 row range. Such a button click and filling the grids should be very low time.
And even if you using a row databound event - once again, it will run fast. But ONLY if you not executing a whole bunch of additional SQL queries. So the number of "hits" or so called SQL statements sent to the database is what for the most part determine the speed of this setup.
So say you have one grid - pulls 100 rows. But then the next grid say needs data based on 100 rows of "new" SQL queries. In that case, what you can often do is fill a reocrdset with the child data - and filter against that recordset, and thus say not have to execute 100 SQL queries, but only 1 query.
So, this will really come down to how many separate SQL queries you execute in total.
To fill 4 grids with 4 queries? I don't see that as being a problem, and thus we are no doubt missing some big "whopper" of a detail you not shared with us.
Expand in your question how many SQL statements are generated in total - that's the bottle neck here. Reduce that, and your performance should be just fine.
And if the 4 simple stored procedures have "cursors" that loop and again generate many SQL commands - get rid of that.
4 basic SQL queries pulls is nothing - something else is at work that you not sharing. Why would each single stored procedure take so very long? That's the detail we are missing here.
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 did a task which geting more than 2 millions record from sqlserver and populate them in Asp.net GridView.
The problem is that, query taking more than 2 minutes in getting record while my query is now fully optimized.
when i move from one page to another by pagination it take again same time and hit server.
so i need a solution where its not take time during page movement or get only 50 or 100 record in each request.
Thanks,
Nauman
Use paging in GridView - check this link
Also adjust display property like display header with available visible cells to load the grid faster.
Its even better if you bind the grid data using jQuery and not from server side.
Use this link to get started
Instead of using GridView you can use repeater or even jQuery templates also with custom paging. that'll be even more fast.
if you are fetching 1000 records and displaying just 50 using pagination, this is really a waste. better to display 50 records each time, this would be much faster. go through the following link:Custom Paging in ASP.Net GridView using SQL Server Stored Procedure
it's problem on sqlserver...
optimization the data base,separate the database and the table
I have implemented paging in Gridview and in order to avoid frequent Reconnection with database,I used Session to store data.So that data could be retrieved from session on changing page index of Gridview.
But my problem is that when should I clear this session as it's usable only for this very page.And if I use ViewState then it will not be fine if data increases in amount.
Looking forward for valuable suggestion of yours.....
Thanks in advance
Supriya
You should not be saving any data to sessions. If the data control requires data per page it is fine to select only the rows you need from the data base per page change.
So if you have say 100 rows and 10 rows per page, then you should be retrieving 10 rows per PageChange of the data control. This is perfectly acceptable especially when combined with caching.
Ifyou are using SQl 2005 see this post:
http://weblogs.asp.net/scottgu/archive/2006/01/07/434787.aspx
I don't think you should worry about the database connections. Connection pooling will take case of that. You have to open connection and close as soon as you get paged records.
If you store your records in viewstate/cache this will unnecesarily use resources and might be out of sync with database. I consider it as a bad approach.
You should make a call each time you change page and retrieve records from db.
Hope it helps.
on my page load I am loading few list, also on my page I have filter conditions which is taking around 30 seconds to get the filtered records from the database, reason : Database is big and I have to navigate to 9 tables to get the list of records depending upon the selected values.
What is the simplest way to achieve asynchronous processing ?
How are you structuring your SQL? If you have to access 9 tables it seems like a view would be a more appropriate solution than joining 9 tables.
When you page load is finished, d an ajax call with jquery to a service. That services generates the output html that you need. You can place a loader in the div/table where the table is going to be displayed
Maybe you should refactor your query, 30 seconds is really long. Are you using keys, indexes, temp tables, full text searches, ect ect to optimize your query