Waste of a few days

I thought I'd post this in case it can help some poor soul out there who could potentially spend days debugging the same ASP.net problem I had...

Symptoms:

• Page loads up fine
• Page mysteriously produces a HTTP 500 Error when a control is clicked on the page.
• Page has always worked before now
• Page has a datagrid populated from a database
• No events fire on the page (or within a control on the page)
• HTTP POST status returns ERROR_INTERNET_CONNECTION_RESET when
• The post stream seems to be truncated
• Code has not changed (file has been in sourcesafe for 6 months!)

Diagnosis:

This problem is caused by the viewstate of the page (which is stored in the page) getting too big. Most HTTP proxy servers have a limit of how much data they can send back to the server in one go. Due to the ever increasing level of data in the database, the datagrid gets bigger. Because the datagrid is stored (along with all the other viewstate enabled controls in the page) in viewstate, this hidden field has also got bigger. If you sniff the http post stream, you see that the output is truncated partway through the viewstate. The server receives a truncated post stream, and in this case sends back an unhelpful message.

Solution:

Delete all your data to reduce the size of the datagrid.

However if your data is important to you or someone who pays you, the best trick is to store the viewstate on the server instead of in the page. The session variable is the best bet of course. Add these two methods to the page giving you troubles (not in any web user control(s) you may be using)

Protected Overrides Function LoadPageStateFromPersistenceMedium() As Object

Return Session("_ViewState")

End Function

Protected Overrides Sub SavePageStateToPersistenceMedium(ByVal viewState As Object)

Session("_ViewState") = viewState

End Sub

Remeber that this is a workaround that will allow the page to function. Unless you are storing session state in sql server you shouldn't use this method for all of your pages to make them smaller. The session variable is stored in server memory and this will degrade performance by filling up RAM and could result in increased hard disk writing when the server has to write to a page file to store the session state. So use carefully, especially with high volume pages...