Wednesday, January 19, 2005

Search Indexers are not just for fun

After ditching Google Desktop in favour of MSN Desktop Search, I today realised the true power of these indexed searched apps. I not only index all my hard disks, but all of our corporate network drives. Today after trying to find some installation instructions for an obscure peice of software, I was told to look in an old network server that I do not index. I resorted to Windows Search to look for the file keywords on that drive.

A few hours later, after find what I needed in a big folder in a bookshelf in someone's office, I sorted out the problem and returned to my desk to catch up on actual work.

Windows search was still going...

If there is a company out there who isn't indexing their corporate networks then they are missing out on a lot of time savings when these issues occur.

Why I love reading tech blogs

Tech blogs rock. My favourites are Scott Hanselman, Don Box, Dan Appleman just to name three. Why do I like reading them so much? I liken it to the really smart person in your office coming up to you and telling you about something really cool that is useful to know. Then times that by a hundred people. But the best part is that with blogs, you can shut the door on all the office time wasters who want to impart 'wisdoms' on politics, sport or business.

btw - I especially love 'bug blogs' - entries where developers blog about bugs which they have discovered (especially when not in beta releases) and how to work around them. By being aware that a bug/trap exists and the scenarios in which I might come across it, that can save me time later. For this reason, I have decided to blog on more of my bug workarounds, or at least the ones that I can't find workarounds for on the web.

Monday, January 17, 2005

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 problem I had...


  • 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)
  • The post stream seems to be truncated
  • Code has not changed (file has been in sourcesafe for 6 months!)


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.


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...