Internally here at Delphic Sage, we use an in-house built task system for assigning bugs or tasks, and to generally get stuff done and / or keep track of it. It has your basic functionality... create and assign tasks, change the status or resolution, add comments. It has become slightly more advanced when we integrated Basecamp into it. It's getting there...

When an employee is assigned a task, they would not know about it unless they had the task system open and were refreshing their list. To alleviate this, and to help Project Managers keep their sanity, we developed a task notification system built on AOL's IM protocol, using a library found on the internet. This library proved to not be reliable. It would lose connection to AIM and it wouldn't report it to the application, so the application would be happily sending task notifications into oblivion, marking them as sent in the database. Luckily, it's not mission critical! Employees will still have the tasks assigned to them, whether or not they get a notification.

In an effort to move toward a more reliable system, we decided to give XMPP and Google Talk a whirl. XMPP (eXtensible Messaging and Presence Protocol) is a standard implemented by many servers and has many different clients supporting it. Since our email here at Delphic Sage is hosted by Google, and every google account comes with a Google Talk account, it would seem to be a logical move. It would also make it easier for future employees to start receiving task notifications immediately. There are some people without AIM accounts, if you can believe it. Read on about our solution...

A few months ago I wrote an ad-hoc SQL script to help with the frustrating task of, "Where is this value coming from in the database?" It can be incredibly useful if you are inheriting a database from another team, or are developing on an open-source database application. The script uses SQLServer 2005 or later to cycle through each table and each column* in all tables to see if that column is equal to some string or value we're seeking. It then returns three result sets:

• List of tables that had a column matching the search criteria
• Table/column pairs of every column that satisfied the WHERE clause
• SQL queries you may run in order to retrieve the matching results (one query per table), with the SELECT returning the matching columns before the full set of columns from the table

Continue reading to view and download the SQL script.

Just last week, I discovered a long known, highly irritating limitation of ASP.NET with regard to the way it handles pathinfo. Worst of all, the problem is impossible to reproduce locally using the Cassini web server that is build into VisualStudio. After banging my head against the wall, I think I came up with a pretty good solution that worked in my particular example, which I will refer to as "Check Box Hell".

A Little Bit of Background

So, you're all proud of yourself because you managed to build a filtering control in .NET that is easy to use anywhere and can create path info URLs so you can pass along the results of a filter to anyone easily (rather than POSTed). Let's assume the part of your filter tool that does path info stuff looks like this:

	// pseudo-ish
	string id, value;
	string pathInfo = "";
	foreach (Control control in wrapperControl.Controls){
		id = control.ID;
		if (control is TextBox && !string.IsNullOrEmpty(((TextBox)control).Text)){
			value = ((TextBox)control).Text;
		}
		else if (control is DropDownList && ((DropDownList).SelectedIndex > 0){
			value = ((DropDownList)control).SelectedValue
		}
		... // other controls

		if (!string.IsNullOrEmpty(value)){
			pathInfo += "/" + id + "=" + Server.UrlPathEncode(value); 
		}
	}

It's fairly simple, and it'll create your path segments that look like this: /txtZipCode=19127/drpState=PA. You test the code locally using the VisualStudio Cassini web server and it works like a champ. Then, you deploy it to your staging server and it is broke like a joke. How could this be? Read on for the solution.