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.
Related
I have a jqGrid for .Net forms and the person who is involved had wanted it done so a license was already in place.
There are other things going on in the page that puts data into a ViewState. Because of the double postback the viewstate will be wiped out in the second postback. We cannot put the information into a session because there is an option where the user could "open in a new window" and hence the session information will not be "separate" as if it was done in a ViewState which is specific to page.
I'm trying to think of a way to preserve the viewstate somehow on the double postback and make it unique for a page.
I was thinking of maybe having a session associated with a GUID but that would carry on through the pages and if I had to update the viewstates in the session it may get ugly.
I was hoping that maybe if I ask here there may be some ideas that I could use.
Thanks
In asp.net, viewstae is it client variable or server variable? how much data can view state is store. I mean if i declare a view state, when more than one user accessing same page is the view state data can conflict or not?
You're really going to want to read this, It covers pretty much all of your questions:
http://msdn.microsoft.com/en-us/library/ms972976.aspx
THe ASP.NET ViewState is a client side hidden control which stores some state data for ASP.NET server controls. The content is Base64 encoded and can be seen with a decoder. It is only available on a postback to the same page. Different users have their own ViewState as it is a client side technology. You can store as much data as you want, but it affects the bandwith. In general you should watch out for large ViewState because it is also not very SEO friendly.
You can use it for your own data like this:
ViewState["myData1"] = someSerializableContent;
ViewState["myData2"] = someSerializableContent;
The ViewState is protected by a hash code to prevent manipulation.
EDIT: Basically you can add as many entries into the ViewState collection as you want. Sometimes it is wise to disable ViewState at all (EnableViewState property). In ASP.NET 4.0 you have more options to disable/enable ViewState by using the ViewStateMode property.
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
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).
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