The LINQ to SQL Visualizer is a phenomenal tool.  This is how debugging should be done.  Scott Guthrie introduced it in the Visual Studio 2008 Beta 2 timeframe, and I’ve been hooked ever since.  It’s now bundled in the Visual Studio 2008 RTM samples, though it’s not installed by default.  Instructions of how to install it are here.

Well, I’m splunking along in some code that happens to be in a transaction.  I’ve just inserted a row, and I’m about to execute the select that refreshes the business object with generated content including the primary key.  I open up the Visualizer, and push the Execute button.  Nothing happens, and the window freezes.

It dawns on me that the unit test’s transaction has locked the row in question, and the Visualizer can’t get to it.  Well, that’s all fine and good, but why wouldn’t it be in the same transaction and/or join the transaction and/or create a rollback point in the transaction in process so the “execute” button can be undone once the window is closed?

I emailed Scott Gu, and he passed on my question.  (Scott is phenomenally awesome with email, by the way.  I can only imagine how many emails he gets from users across the globe, and each time I email, I get a personal response.  I hope I can be that awesome when I grow up and get an office with a window.)  The answer came from a tech that Visualizers don’t use the same app domain as Visual Studio, so reusing the connection was impossible, making subscribing to the transaction also impossible.

Since this is sample code, and thus the code is provided, I’d like to take a stab on an off hour changing the sample to store the SqlConnection (or IDbConnection) rather than the ConnectionString and see if it works.  I expect it won’t, but if it did, wouldn’t it be cool?

In the mean time, I’ll just remember to look in the LINQ to SQL Visualizer but not execute if I’m inside a transaction.  If I’m that curious, I’ll grab the query, finish the transaction, and execute it inside Sql Management Studio or LinqPad.

Rob