Project option: Ignore Temporal artifacts

billinkfc

For "reasons" we have our development environment created without temporal accoutrement. Once tables are promoted out of the development tier, we need to have those tables defined as temporal tables.

I'd like to see in a future version of SQL Compare a project option that ignores the row start/row end and period specifications. As it stands now, I have 1276 tables that differ between Dev and QA. I *think* every one of those changes is due to the temporal specifications but it's going to be a bear going through that change script.

Every time I need to sync environments, I will need to repeat this painful process. Currently, I'm looking at emitting the change set to xml and shredding that and discarding temporal changes but that just smacks of "I'm going to miss a case, might not even be a corner case"

Again, reasons for why we have to have the environments set up and changing the product will be easier than their process. Not good reasons mind you, but standard, unfathomable and unyielding corporate "reasons."

sam.blackburn

Do you basically want the behaviour SQL Compare had before we implemented temporal table support? As a temporary fix you could try using SQL Compare 12.1; it would be useful for us to know whether this does approximately what you want so we can work out how difficult it would be to ignore temporality.

StephenACarpenter

Is there any traction for changes like this?  We'd like to do comparisons while ignoring Temporal table related objects, such as the columns designated GENERATED ALWAYS AS ROW START/END etc as well as the History Tables.