Brandie Tarvin (1/17/2013)
chuck.hamilton (1/17/2013)
SQL Server now decides that synchronization between the subscriber and publisher is more important than durability of a committed transaction and quietly issues a system delete for that row back on the publisher. In the end, a committed insert simply disappears.I've seen this happen with merge replication, and I believe it's also a problem with transactional replication. IMO this is a big mistake.
Hence it actually is subscribing to the very first rule of ACID (Atomicity).
Unfortunately, SQL does this SILENTLY - which means anything the input system has set up to deal with a failed transaction is circumvented. The system must rely on user reports for "disappeared" transactions for which there are now no records. In systems where ANY transaction (even failed ones) are considered important (and are preserved as records in the database) - having silent rollbacks with NO alerts will drive IT more than a little :crazy: