Thanks, Kevin.

In the meantime at least IE8 got installed, but VS SP1 is still going...

>
>>- Can they name the 5 transaction isolation levels, and the behavior of each one?
>
>I would not answer this question from the top of my head - need to do a research.
>
>Not trying to be harsh, but there are people bounced from interviews for not knowing this. Sad but true fact of life.
>
>Here....my Memorial Day gift to you....
>
>1) Read uncommitted (Dirty read).....fastest, no "locking", but most prone to data integrity issues. It will read uncommitted data. So if I start a transaction and update a row......and then you read the row......and then I rollback the transaction....you wind up reading the "dirty" (uncommitted data). There "can" be specific instances where this is OK to use, but must be used with care.
>
>2) Read committed (default behavior).....like the name says, will only read committed data. So if I start a transaction and update a row....and you try to read the row in a query.....you're "locked" until my transaction completes, and then you read the row after the transaction completes.
>
>3) Repeatable read (not used very often).....in a stored proc, I read a row and get value 'A'......and then later in the stored proc, I read the same row again. Now, you "could" sneak in between my first and second read, and change it to 'B'.....which means that the 2nd time around, I get a different value than I previously got. But repeatable read keeps things consistent for me.....your change to 'B' will be locked out until my stored proc finishes.
>
>4) Serializable (a.k.a. the "perfect" transaction)....basically does a lock. (there's more to it than that, but you can investigate this one on your own) :)
>
>With each level, you have an increasing level of protection, and more resources are used (and greater chance that someone will get locked out, even if briefly)
>
>Those were the 4 levels prior to 2005. But many people wanted the performance/flexibility of a dirty read, but also the protection offered by read committed. They didn't want people to get locked out, but didn't want people reading dirty data. So 2005 introduced the new snapshot isolation level. This level takes a snapshot into the tempDB database, so that you can uqery against a version of the data throughout the entire transaction, without having to wait for locks to clear, and without reading from "dirty data". Of course, this needs to be used wisely, as someone can overload the server by using this excessively.
>
>OK, ego intact, I typed this from memory....didn't read from my notes, didn't tab over to SSMS.....of course, I've been teaching this for 2 years now, so it's second nature. But anyone who can talk through this in an interview is probably like to do well.
>
>
>And yes, on your other question, I meant the MERGE command.