IGNORE_DUP_KEY = ON
basically tells SQL Server to insert non-duplicate rows, but silently ignore any duplicates; the default behavior is to raise an error and a
I'm having a many-to-many relation. I have a product-to-category table with unique index, no other data than prodid and katid in table.
So I'm setting IGNORE_DUP_KEY on the unique (prodid,katid) index.
So I can safely say "add product (1,2,3) to category (a,b,c)" without having to check if some products are in some categories already; I only care about the end result.
It can be used as a sanity check. If you know that there should be no conflicts leave it off and it will fail fast on bugs. OTOH for ad-hoc console sessions, I see your point.
Whenever there is a deviation from the "normal" in the database , you probably want to know about it.
You kept the key unique because of some constraint arising out of business need that dictated it. The database is just keeping up it's side of the deal saying that 'hey you wanted this to be unique but now you are saying something contrary. Make up your mind'
If that is intentional you can ask database to shut up by using IGNORE_DUP_KEY :)
I guess it might be because the defaults are set to prevent any invalid transactions from failing silently. Everything considered, I'd prefer to choose when to ignore unintended consequences, but please let me know unless I say otherwise.
Example: If I'm depositing my paycheck, I'd like someone to notice if my employer accidentally issued duplicate check numbers.
chances are the duplicates are in there by mistake anyway.
I bet they are! They are bugs. You certainly want to know about them! Turing on IGNORE_DUP_KEY
by default is...
This is a terrible choice by any standard.
Turn it on under special circumstances and then get rid of it as fast as you can so you don't accidentally hide bugs.