Our factory-floor PLC devices write continuously to a database OPERATION. At the end of the shift several reports are generated and the data is then summarised into an archive database and the records are deleted from the OPERATION database. This is done automatically by the third-party Operation software and is not something we have control of.
The business developed the need to be able to analyse and report on some of the historical detailed data (the summarised data was deficient) so I implemented Transactional Replication for the relevant tables, publishing from the OPERATION database to a subscriber database BUSINESS. At the Publisher I set the Article Properties for the Tables' DELETE delivery format to be Do not replicate DELETE statements.
Recently the software vendor was upgrading the Operation software and was having a problem due to the "pesky replication" so he deleted the Publication!! (What the???) I only found out about this toward the end of the day because somebody noticed no data was coming across to BUSINESS. By the time I figured out what had happened I was under time pressure to fix it because the automatic process was going to shortly delete the detailed data from OPERATION. I quickly setup the replication and did a Snapshot...and successfully blew away 18 months worth of history on BUSINESS. (sigh)
I restored a backup of BUSINESS to a database BUSINESSRESTORE so I now have historical and current data on the server, but due to the reports that have been written the business needs me to merge the historical data back into the BUSINESS database. I realise this will make the Publisher and the Subscriber inconsistent but it occurred to me that SQL Server is doing the same itself by the implementation of the option Do not replicate DELETE statements so there must be an "okay" way to do this.
Can I please have suggestions for a safe way to achieve this?
Bonus problem: The Operation software update seems to have reset the Identity columns in the OPERATION database tables - they're currently around the eighty thousand mark. Because the software had been running for a long time before I implemented replication my earliest ID in BUSINESS is around the three million mark so I could theoretically merge the records together and not have any clashes for a while, but I'd rather do it sensibly the first time around.