>>>Create a sandbox copy of your live data to perform each test in, and let it process normally. After validating it is correct, delete the sandbox, or re-initialize it to its "default / empty" state.
>>
>>Yes, this is nice. But, in production, where needed to enable the startup of a rollback transaction in regards to various SQL commands executed in sequence, where one involves a child table based on a newly created record from a parent table from within this transaction, how would you see such possibility of rollbacks?
>
>
>The method I use for creating new records is somewhat different than other people. It goes like this:
>
>I don't do a BEGIN TRANSACTION and populate the destination tables. I load the data into a copy of the destination tables, assigning all primary keys up front, and then use those small tables for all processing. Once the user has input the data and it's ready to be saved, I test my rules against the copy and the actual data, and then I know that the data going from my copy into production is valid, has passed all business rule tests, has all unique keys, etc. At that point, I do BEGIN TRANSACTION, populate each table, and END TRANSACTION, that way the only way it would ever back out is if there is a hard system error.
>
>I haven't seen this model in wide use because it usually requires more programming. However, it prevents a large number of different kinds of synchronization errors, allowing also an entire transaction to be saved into a "draft status" for later retrieval and completion.

Aren't you replicating the built-in transaction support on your own?