I was hoping to use LinqPad to see what the actual state of the db is while stepping through a unit test of NHibernate mappings while in the debugger.

I was hoping I could do things like examining the results of "select * from users" at different points in the test run, but it looks like the connection is hung until the test is finished.

Does it make sense what I'm trying to do? Should I be able to use LinqPad to do it?

Thanks,

You can call Dump at any time to see intermediate state. Dump() returns whatever was passed into it, making it convenient to insert within queries.

For instance:

Customers.Dump("all customers")
.Where (c => c.Name.StartsWith ("a')).Dump ("after filtering)
.OrderBy (c => c.Name).Dump ("after ordering")
.Select (c => c.Name)

Does this answer your question?

Hi Joseph

What I'm really trying to ask is if I can somehow use query the db state while I'm stepping through a unit test in visual studio that is affecting changes to the db.

When I try to do this LinqPad says it's executing my query but doesn't do anything but wait, presumably because the db connection is being used by the unit test. I've seen SSMS used as a db inspection tool during a unit test and am hoping I can get LinqPad to do the same.

Does my intention seem clear? Is this possible with LinqPad?

Thanks!
Berryl



This post has been edited by SJ22: Jul 6 2009, 09:23 AM

So are you initiating the unit test from LINQPad - or Visual Studio?

Visual Studio

I'm initiating the test from VS.

Thanks!

Hi Joe

The answer to your question is that the unit test is initiated in Visual Studio.

Thanks for the prompt reply!

I'm still not quite sure of the problem.

Is it that when you have several queries in a batch, LINQPad doesn't display the results of queries immediately - but only once they've all completed?

Joe

Joe:

Here is what I want to happen:

1) start a debug unit session in visual studio using connection db1
2) step over a line that modifies the database in some fashion
3) ** inspect db1 (in LinqPad this could be as simple as "select * from customers")

The problem then:
is that while the unit test is active, LinqPad just hangs; when the unit test is finished then my test fixture will roll any transactions back.

Berryl

This post has been edited by SJ22: Jul 16 2009, 12:52 PM

I'm with you now.

The problem is almost certainly that you need LINQPad to use a READ UNCOMMITTED transaction isolation level. This will prevent it from being blocked by active transactions.

A couple of people have asked for this.

Scott Hanselman has also blogged on general topic of setting tx isolation levels in SQL to SQL. Which of his suggested approaches would you prefer?