Ok, I'll try to come up with one hypothetical one.

But at first I need to put few sentences:

1. "booking" system could be actually any transactional system. I just held an example in my head which would be relevant for booking or stock management.

2. I guess many will agree that READ_COMMITTED_SNAPSHOT is not a magic bullet against all locking problems in your database! When you design and code you should be aware of locking issues and design/code appropriately.

Now an example. "booking" system...

Let say Customer "A" does want to book one Seat and his highest priority is to book a seat #1. At the same (or almost the same) time Customer "B" wants top do exactly the same!

So small setup:

CREATE TABLE Booking (ID INT IDENTITY(1,1), SeatID INT, CustomerID CHAR(1))

INSERT Booking SELECT 1, NULL

INSERT Booking SELECT 2, NULL

Now let see how booking system will process reservations without READ_COMMITTED_SNAPSHOT:

ALTER DATABASE MyDev

SET ALLOW_SNAPSHOT_ISOLATION OFF;

ALTER DATABASE MyDev

SET READ_COMMITTED_SNAPSHOT OFF;

For a Customer A, started first - hence his transaction begins first (SSMS query window 1):

BEGIN TRANSACTION

-- Book seat 1 if it's not already taken

IF NOT EXISTS (SELECT 1 FROM Booking WHERE SeatID = 1 AND CustomerID IS NOT NULL)

BEGIN

UPDATE Booking SET CustomerID = 'A' WHERE SeatID = 1

END

-- Now let say we need to do something else as part of the booking transaction which

-- takes some considerate amount of time for this Customer

-- do not commit for now!

So, while transaction for Customer "A" is still running Customer "B" presses the "Book" button, so his transaction kick's in (SSMS query window 2):

BEGIN TRANSACTION

-- Book seat 1 if it's not already taken (and it's not as transaction for Customer A is not committed as yet).

IF NOT EXISTS (SELECT 1 FROM Booking WHERE SeatID = 1 AND CustomerID IS NOT NULL)

BEGIN

UPDATE Booking SET CustomerID = 'B' WHERE SeatID = 1

END

-- Now let say that "something else - part" for Customer "B" takes no time and transaction is completed, so:

COMMIT TRANSACTION

Yeah, our second transaction is running as it cannot commit waiting for the first one to release the lock. Lets do it. Add COMMIT TRANSACTION into first query (SSMS window 1) and execute it.

So. All transactions are now committed (you can check window 2). Let see what we have in result?

SELECT * FROM Booking

As expected we have:

Now turn is for READ_COMMITTED_SNAPSHOT (make sure that you have only one connection to your database open, otherwise SET READ_COMMITTED_SNAPSHOT OFF will run for ever ;-)):

ALTER DATABASE MyDev

SET ALLOW_SNAPSHOT_ISOLATION ON

ALTER DATABASE MyDev

SET READ_COMMITTED_SNAPSHOT ON

Repeat all steps in exactly the same order as previously.

Check results.

Surprise!!!!

You will have Customer "B" much more lucky this time!

Oops....

Yes, you will tell me that my code is not good enough, and you will be right - it's a crap code.

But that is not a point I wanted to make. What I've tried to say is:

If you have a crap code which did work without READ_COMMITTED_SNAPSHOT, you will still get it working fine with READ_COMMITTED_SNAPSHOT ON, except one caveat: it may produce a bit different results...

So, refer to the point #2 at the beginning of my post.