Help get this topic noticed by sharing it on Twitter, Facebook, or email.

Using Temporal Tables for SQL Server 2016

Since Sql server 2016, we have a new feature called temporal tables.

This will allow us to keep tracking all records. When we do sf_refresh, or sf_replicate, can we utilizing this feature? It's much more powerfull than the SF history tracking.
1 person likes
this idea
+1
Reply
  • We are not familiar with Temporal Tables and their compatibility with DBAmp. We will take a look and let you know what we find out.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated

  • This is doable with some caveats.
    1) Some of the fidelity of data will be lost based on the frequency of refresh. For example, if multiple edits were made to a record before the refresh proc ran, it would only capture the final change as the delta between the original record and the current one.

    2) The table created by DBAmp would need to stay unchanged if you were going to use the packed-in stored procedure with DBAmp to refresh the data. You'd need to configure a trigger on the replicated table to update a copy of the table that had the temporal features turned on; this way any insert update and delete in the original table, the temporal version got the change too.
    A cleaner solution would be to make a customized version of the sf_refresh proc that dealt with the additional table columns.

    If Bill is interested, I'd be willing to write this up.
  • (some HTML allowed)
    How does this make you feel?
    Add Image
    I'm

    e.g. happy, confident, thankful, excited kidding, amused, unsure, silly indifferent, undecided, unconcerned sad, anxious, confused, frustrated