• mar10br0 (4/26/2011)


    Great article Solomon!

    I do however avoid triggers like the plague in production-code as a principle...I much more take rbarbati's approach in an earlier reply-post, for this I prepare ALL my tables to ALWAYS include a timestamp-column, so I can find updated/inserted rows since a certain time.

    Hello. Thanks for the compliment and the additional input. As with my reply to rbarbati, in my experience the Triggers have not been a problem, even in a SaaS environment with 24/7 access to the Table. But again, circumstances for someone else might be different and so having another method to handle the data sync is certainly valuable and appreciated. I think you could accomplish the same goal as your method with a regular DATETIME field as opposed to TIMESTAMP / ROWVERSION, which would also be human-readable though not any more functional than the TIMESTAMP (just a thought I had as I was reading your comment).

    However, and I forgot to mention this in my reply to rbarbati, one advantage of the Trigger method is that the data is ALWAYS up to date without a secondary process (which takes time to run) to accomplish the sync. Since we have data changing all of the time, if we did not have a Trigger then we could run into a case where we sync the data and start the process of swapping the Tables but then a change occurs and there would have to be an additional step to see if any new rows exist in the DELETEME table and if so, then move them back into the "new" current table.

    Take care,

    Solomon...

    SQL#https://SQLsharp.com/ ( SQLCLR library ofover 340 Functions and Procedures)
    Sql Quantum Lifthttps://SqlQuantumLift.com/ ( company )
    Sql Quantum Leaphttps://SqlQuantumLeap.com/ ( blog )
    Info sitesCollations     •     Module Signing     •     SQLCLR