SQL Server database snapshots for integration testing

Unfortunately, it's by design.

Taken from BOL page "Revert a Database to a Database Snapshot":

Limitations and Restrictions

Reverting is unsupported under the following conditions:

• The database must currently have only one database snapshot, to which you plan to revert.
• Any read-only or compressed filegroups exist in the database.
• Any files are now offline but were online when the snapshot was created

As an alternative, you could drop the first snapshot (db)_Basis. I can understand that this seems very limiting but look at it this way: snapshots are sparse files based on the original data files, so reverting to a specific snapshot would invalidate all snapshots anyway (the base data files would be changed by the revert operation). The limitation can be annoying, but doesn't look unreasonable.

Another perspective will be to take backups and restore them - since you are just creating empty database and schema with some lookup values.

Also, just inserting 50K rows, the database wont be that big. If you use compression the backup size will be less as well.

You can have a TSQL Agent jobs or just scripts (may be you can create stored procedure and just call it after your tests based on the output you get).

• Base backup - (db)_Basis
• With testdata backup - (db)_With_Testdata

have your integration scripts run and based on the final output, you can run either of the above jobs to revert to what ever point you want.

I feel that backup/restore method is much elegant in your scenario since you are hitting database snapshot limitation. Also, Paul Randal blogged about a nasty bug in all versions up to and including SQL Server 2012 (not sure if it is fixed in a later CU)

When you revert to the database snapshot, the transaction log file of the source database is ripped out and replace with a 0.5MB log file with two 0.25MB VLFs.