>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.

It is very interesting but, yes, very rare, becase as you said, it requires an overload of support.

Thanks