ViewState is a great tool that people shouldn't be afraid of. In cases where the ViewState is rather large and its not feasible to send the information to the user and you do not want to re-query the data source (maybe because it takes longer than desired) you can inherit from System.Web.UI.Page and overload the methods associated with loading/saving ViewState and have it stored in a database much like the Session state in SqlServer mode.

The way I did it was to register a new hidden form field called __VIEWSTATEGUID that had a GUID value that would identify the row in the database. I also allowed for a TimeOut of the ViewState information. So you could set it per page if you needed.

I have seen production applications go from slow and bulky page responses to super quick and speedy. The two extra round trips (load/save) is not even noticable. I would suggest you research this further as a viable solution to ViewState bloat.

Hi, you can also compress ViewState - I made a start on this here: http://www.mostlylucid.co.uk/posts/694.aspx

Scott, compressing is cool, it will save on the precious bandwitch.
But my main point is that you don't need the viewstate at all for most controls. Default it is switched on, one of the fisrt things you should do after dropping a control on your form is disable the viewstate.

I have heard that when viewstate reaches a limit, proxy servers tend to truncate it. I would like to know how can I set that size OR which factors decide upto what size proxy server would allow without any alter.

Thanks,

dgoyani

dgoyani@gmail.com