I recommend a third approach applying a new staging table and history table in Database B on Server B. The staging table will mostly mirror your Table B, but will not contain any constraints and will have an additional bit column defining Status. The history table will mostly mirror the Table B structure but will contain two additional columns (ChangeDate and ChangeMade). Lastly, for this approach you will need to identify the column(s) used to define the records from the View as unique.
- Truncate Staging table (from previous results).
- Export data from View (Server A) to staging table (Server B).
- Run SQL task to check for consistency and quality of each record. Those records that pass, set the Status bit field value to 1, otherwise set to 0.
- Apply a MERGE call in a SQL Task to both transform the data from the source (Staging table) to the target table (Table B) and update the History table. This is only applied for those records that have a Status = 1. With the MERGE you can also OUTPUT the history of what was changed to the new History table indicating "I" for insert, "U" for update or "D" for delete based on the matching defined in the MERGE.
- For those records in the Staging table with a value of 0, send an email to whoever needs to know that X number of problem records were found.
The idea here is that the process doesn't come to a halt and you do not need to force a rollback if a single bad record is found. Also, you can monitor the daily process by viewing the Staging table. I've taken this approach in the past and integrated into it sending email alerts with links to SSRS reports reporting on the problem records. Doing so allowed me to proactively find patterns in the problem records and work with those upstream of me to resolve the problems. If you have over a million records being pulled by the view, then you may want to add to the Staging table a surrogate key (set up as a primary) with an identity starting at 1 and that automatically increments by 1 with each new record imported from the view. Just before running the MERGE, set up a clustered index using the surrogate key. This will greatly improve the performance of the MERGE. Just before truncating Staging table in the first step, drop the index.
Hope this helps.