Question

The problem is during inserting data from staging table during import routine.

The system is a legacy one I inherited, and short term while I develop something more suitable I want to patch things to avoid the data transfer failing.

Unfortunately the facility exists via another application to create an entry into table, called CommReceipt. The key is called CR_Key . if this happens then when the auto routine runs to insert, say 1000 rows we need to import from another system (not my system) with CR_Key values already defined, it fails.

The way I see it I have several options, but all suggestions will be appreciated moving forward for the best solution to this issue (both long and short term fixes) .

It is part of the plan to eliminate functionality in the rogue application (but this is a legacy system, written in legacy unfamilar language and might take a bit of effort)

How do I deal with the primary key violation. Can I continue, reporting the violation to deal with after running data insert.

UPDATE: the Primary key CR_Key also happens to be an identity , is there a way to delete rows which should not be there and insert rows using the same ID. I presume….I turn the identity off, then specify unique values in the ‘missing rows’, is that plausible?
I don’t need to auto increment id now, theinsert routine has ID’s

Thanks

Answer 1

You could use an instead of insert trigger. Inside the trigger, do an Insert into the table, where not exists CommReceipt.CR_Key = inserted.CR_Key.

Create trigger T_CommReceiptInsteadOfInsert on CommReceipt
Instead of Insert
As
Begin

--Insert duplicate records into another table
Insert Into CommReceipt_Duplicates(CR_Key, ...)
Select CR_Key, ...
From inserted i
Where exists (select * from CommReceipt c Where c.CR_Key = i.CR_Key)

--Insert non duplicate records
Insert Into CommReceipt(CR_Key, ...)
Select CR_Key, ...
From inserted i
Where not exists (select * from CommReceipt c Where c.CR_Key = i.CR_Key)

End