I'm using a Gridview to hold records that user can click on the checkbox in each record for indication that he/she want to save that record(after editing the data) and user can select as many records as they want and save them all at once.
In the code behind, I'll loop thour the gridview and look for the checkbox to save the record. If I disable the Gridview's view state. I can't loop it but if i enabled the gridview's viewstate then the gridview view state can go as high as 1mb and beyond.
what will be the best way to reduce the viewstate on this girdview control or is my approach is wrong?
If you can't reduce the size of your viewstate you could try an alternate solution. You can store your viewstate on the server. This blog post shows how to implement this:
Reducing the page size by storing ViewState on Server
I've implemented something similar to this on a page that had a huge viewstate and it worked great. I would try to optimize the viewstate before moving to something like this since it is creating a bit of overhead.
I think I used this article (it's been a while) and had to modify it for SQL as this uses the filesystem:
Persisting View State to the File System
If you're open to the idea you might want to consider implementing custom paging to reduce the number of records returned. Perhaps start with the default paging but that returns all records. If you want better performance custom paging is the way to go.
Some helpful material:
Efficiently Paging Through Large Amounts of Data
GridView ObjectDataSource LINQ Paging and Sorting
Improve GridView Performance by Delegating Paging to SQL Server
I agree with Alex. You could also ues a temp table to hold the data. I used this scenario on a project and it works fine. You could also use caching, but again that's puting the load on the web server (unless you have some sort of distributed caching).
Related
I have a listview on my page that can display 10,000 or more rows.
There's a simple 'customer' drop down on the top of the page that does an auto-postback to change the data filter. I've been trying to optimize this routine and I noticed that the majority of the time is spent transferring the ViewState from the client to server.
I've added EnableViewState="false" to the ListView control but it doesn't change it. I've looked at the request in Fiddler and if the customer on screen has say 50 rows, the request content length is low - if they have 10,000 or something it's huge.
Anyone have a fix?
This is happening because data-bound control (including list view) would store their data-source into the view-state. So view-state will be large cause page size bloat.
One of the solution is to disable the view-state for list-view and bind it every time page posts back.
Even better solution is to do data store side paging i.e. if you are showing only 50 rows then fetch only 50 rows from the database. This is typically referred as custom paging in ASP.NET and you can find several examples for custom paging for your data access technology. For example,
custom paging uing Entity Framework & ObjectDataSource: http://geekswithblogs.net/Frez/articles/using-the-entity-framework-and-the-objectdatasource-custom-paging.aspx
You can use SQL Server ranking functions to do paging in a stored procedure: http://msdn.microsoft.com/en-us/library/bb445504.aspx
I have a situation where
User can enter multiple prices for an item
All data is kept in datatable or datasets inside viewstate until the
form is saved
All add/update/deletes are performed in viewstate again
Griviews are placed inside update panels to show these operations
Problem I am having right now is that my webforms have gone really slow due to many update panels on the page, page size is touching about 800 KB due to all viewstate information.
Is there a way I can replace the updatepanel and gridviews altogether with a different approach ?
How can I replace current situation with
JQuery ?
What would be the implementation steps (not code just steps) to setup my current task with JQuery ?
You really shouldn't use ViewState for that. Consider storing your DataTables and DataSets in session state instead.
I am using framework 2.0, and I don't understand how the datagrid and the datasets works after doing a postback. In msdn says that there's no need to do a databind again if the request is a postback. But my question is: how the datagrid shows again the records if there is no databind? I supose that asp.net saves in a cache the query results, but I am not sure. Please tell me what is the mechanism that .NET uses to accomplish it.
I have a large query result (hundreds), paginated each 50 records, and I want to avoid doing the same query every time the user select the next 50 records.
Thanks in advance.
The answer to this is the viewstate. The whole displayed grid is stored in the viewstate and it is this that persists across postbacks.
That is the grid is defined on the initial page load and stored in the viewstate. When the user clicks a link/button to postback the form the viewstate is then decoded and is available for use again. Therefore you don't need to rebind the grid. However said there are some caveats to be aware of.
ASP.NET saves your previous values into ViewState, so they aren't get lost between postbacks.
But in your case you're talking about pagination, the new records. If you're retrieving them at first request, maybe you can store them at viewstate but it's not a good idea. Your page will be served very slow if you have much records.
If your clients getting the same data every time, and the current data changes are not important while showing data, maybe you can cache it with asp.net's caching mechanism.
Viewstate is the magic word :P
ASP.NET WebForms is all about ViewState.
The concept is basically that ASP.NET is storing the information in a hidden input element on your page and then automatically retrieving it server side using postbacks, which posts the form (wrapped around your whole site) back to the server.
can we store viewstate other than in hidden field in asp.net
Yes. There are a number of different implementations out there for moving ViewState to Sql Server, for example. But often, when you want to do this a better option is to make a few smaller changes to your site to reduce the number of postbacks and the amount of information placed in viewstate in the first place.
Try this: Moving ViewState to the Session Object and more Wrongheadedness
Is there a way to avoid postbacks with gridview every time a row is added to it?
In other words, can I store the DataTable on the client and pass it on to the server control when I am done to save, rather than do postbacks every time the row is added?
I searched and searched....all I could find was web services, JSON, and I have a feeling it's redundant here...it's a simple task I am sure everyone had to do at some point.
Can anyone shed some light on this?
There is no avoiding postbacks if you're dealing with a standard ASP.NET GridView that utilizes ViewState.
You can however, disable ViewState and manually (programmatically) render the control on every page load. This will let you control every aspect of row creation/removal/updates, but you'll have to do it all manually. And yes, you'll utilize AJAX to read from or update on the server.
I don't konw of anything that lets you do that with the gridview out of the box, except the UpdatePanel, but that doesn't really count. If you want to implement I a full AJAX grid I would look into using the ListView Control, which will give you much more control over the resulting html.
Heres a great article from MSDN Magazine http://msdn.microsoft.com/en-us/magazine/cc337898.aspx