Being a creature of habit could kill ya ...
I was being a good little boy and using the data application blocks in my latest project. I was trying to do something cool where my component would support the ability to pass in a shared connection so you could reuse it. However, my manager set the requirement that he wanted to simply be able to call the method without having to instantiate a connection object himself.
Fair enough I thought, easily attainable through method overloading. I would simply have an overload that doesn't accept a connection. Here, I would open a connection, do my data access, then close the connection. Unfortunately, it doesn't quite work that way. I was getting a bug were any data reader returned by my component wasn't open. "Ok" I thought, "that's because I'm closing the connection before returning the reader". I remembered that the ExecuteReader method has an overload where you can pass in a CommandBehivior. One of the values in the enum is CloseConnection ... which means that when you close the data reader, it closes the underlying connection. Perfect, I've dealt with this before so I figured I would just comment out the connection close.
Crap! I was using the application blocks so I didn't even have direct access to the ExecuteReader method ... thankfully, Microsoft gives you the code when you download the blocks so a bit of sleuthing showed me that if you pass in a connection string instead of a connection, the application block does just that for you, opens a connection and executes with CommandBehavior.CloseConnection.
D'oh! the code was sitting there all along ... oh well, you live and learn :-)