Ye Gods! How could this possibly happen?!? Thousands of years of mathematics and physics turned on its head from one simple SELECT statement!

I’ll tell you how it happens… SQL Server has to break this query into a step-by-step plan… and, in its nearly infinite wisdom, it may decide to do things in an order you did not expect.

For example, it may decide to filter out the SalesDate part first, then do all the joins, and then the division and THEN filter on the TotalQuality clause. If this is the plan it chooses, and you have zeroes for TotalQuantity… BLAMMO! You just got yourself a divide-by-zero before you even got to the last filter step which would have saved you.

The ONLY way to guarantee this doesn’t happen is to use a CASE statement in your SELECT as follows. It’s ugly, but safe:

Did you know that ADO.Net leaks isolation levels across pooled connections?

This is particularly bad if you’re trying to use Snapshot isolation in SQL Server 2005+.

So, let’s say you create an ADO.NET connection (say, from Entity Framework) and do an update… you’re fierce about your data integrity, so you set your isolation level to Serializable… or you use TransactionScope and don’t bother to specify an isolation level and you get the default of Serializable (ye gods!)

When you’re done, that connection goes back into pool.

Now you open a new connection to and try to read data from a snapshot database with a simple select statement. That connection you just got came off the pool, but with Serializable isolation level still set!

Now, rather than the beautiful clean, non-blocking read you were hoping for, you get a blocked read… exactly the thing you hoped snapshot isolation would prevent!

The problem, essentially, is that sp_resetconnection does not reset the isolation level. You need to do this manually, or use different connection strings for updates/reads so you don’t grab the same connections off the pool.

We have a lot of complex editors on our site. We often find ourselves needing to track changes within a complex view model. With the ability to extend knockout observables, you can create some really useful and reusable tools to go along with the already powerful knockout framework.

To begin, you’ll need to extend the knockout observable with a change tracking extension. The power of extending the observable lies in the ability to hang additional observables off the observable, itself. With these, we’ll be able to track the observable’s original state and provide an isDirty computed column that can then be interrogated at the view model level. This version handles numbers and strings pretty well, but you might have to do some more coding to deal with dates or more complicated values.

It would be cool to be able to run this on the view model as a whole and it would spider over the entire model, including observable arrays, and track changes all the way down. If it could be made generic, it would make a nice GitHub project.