How poor is this practice?

Question

We have applications at work that spend most of the day rolling back insert statements because of attempts to insert dupe data into a unique indexed table.
How poor is this practice to eliminate duplicates?
It seems to be a common practice by those use to working with SQL Server.
Why is it any different in SQL Server than Oracle?

Answer 1

>
It is evident the developer has chosen the lazy way to deal with the dupes by introducing a unique index that uses a natural key but for whatever reason he sees this natural key repeat over and over thru out the day.
His code uses insert all into so that he can insert in batches and probably doesn't even realize he loses his entire batch whenever there is a dupe on insert.
>
Well you need to modify the process as suggested by me and others.
IMHO the simplest way is to use the MERGE statement and the NOT MATCHED condition. That allows you to insert the new rows while ignoring the matched rows.
See MERGE in the SQL Language doc
http://docs.oracle.com/cd/B28359_01/server.111/b28286/statements_9016.htm
>
MERGE Purpose
Use the MERGE statement to select rows from one or more sources for update
>
Here is an Oracle-base example
http://www.oracle-base.com/articles/10g/merge-enhancements-10g.php
Optional Clauses
The MATCHED and NOT MATCHED clauses are now optional making all of the following examples valid.
-- Both clauses present.
MERGE INTO test1 a
  USING all_objects b
    ON (a.object_id = b.object_id)
  WHEN MATCHED THEN
    UPDATE SET a.status = b.status
  WHEN NOT MATCHED THEN
    INSERT (object_id, status)
    VALUES (b.object_id, b.status);
-- No matched clause, insert only.
MERGE INTO test1 a
  USING all_objects b
    ON (a.object_id = b.object_id)
  WHEN NOT MATCHED THEN
    INSERT (object_id, status)
    VALUES (b.object_id, b.status);
-- No not-matched clause, update only.
MERGE INTO test1 a
  USING all_objects b
    ON (a.object_id = b.object_id)
  WHEN MATCHED THEN
    UPDATE SET a.status = b.status;The second example above will 'ignore' the duplicates.
My second choice would be to use DML error logging.