|
Comments
|
Douglas Webb on
2/23/2009
decent
|
|
luther smith on
2/23/2009
Simple, quick and easy
|
|
|
This goes to show that I need to learn more about the error logging available in SQL Server.
|
|
|
When you changed the order of the table inserts you should have done a switch on the entire insert statement, not just change the table name. That could lead someone astray if the insert statements for the 2 tables are not identical.
|
|
|
excellent
|
|
|
It could be explained in part 2.. seriously.
|
|
|
ok what he said made sense but he didn't demonstrate it working correctly as the procedures were still executing at the end of the video!
|
|
Charlie Bruno on
1/13/2011
It appears the changes to the stored procedure that Jon made did not work. But the explanation of the resolution was understood.
|
|
Keith Mescha on
1/13/2011
It didn't seem like a very real life example and not sure the demo even ended up working.
|
|
|
The fix example is a bit simplistic. Would like to see a more involved troubleshooting example, but perhaps that will come later... :-)
|
|
Craig Pessano on
1/13/2011
Are there any plans to cover other scenarios such as when the deadlocked resource is an index that is being updated?
|
|
Maurice Ivory on
1/14/2011
Learned something I didn't know.
|
|
|
What happened? The query didn't complete!
|
|
|
Although a deadlock didn't occur I think the queries never completed due to the table locks still in the statement?
|
|
|
This would help to be able to run the scripts outside the video for testing
|
|
|
transaction batch should be small enough for this short demo to show that both transactions finished without a deadlock.
|
|
Maurice Ivory on
12/12/2011
It was good final part to deadlocking.
|
|
|
Video is incomplete
|