[quoted text, click to view] > If you *really* don't like subqueries and you have a primary key
> constraint on those 2 columns, then you could always just do the insert
> (without the WHERE clause) and ignore/suppress any errors that occur as
> a result of violating the PK constraint. The constraint would take care
> of rolling back the transaction so the dup row does not get inserted
> into the table.
Therein lies my indecision.
The "corporate culture" here is one of vast "sloppitude". They have years
and years worth of VBA and VB6 code that does stuff like this:
On Error Resume Next
' Insert a bazillion items with massive duplications to a unique set of
columns
' go merrily on your way
And I am trying to discipline them to not do that.
The sub-select works, and has a decent looking execution plan, I just have
an irrational distaste of the sub-select, and avoid it when I can. I was
just here polling to see if anyone had other techniques. I understand that
your comments will also work, but they do WAY TOO MUCH of that sort of thing
here already.
[quoted text, click to view] > The EXISTS() predicate is usually pretty good (as it stops the index
> scan as soon as it finds a matching row), although you picked the one
> case where it will most likely scan the entire index, that is when there
> is no matching row (i.e. the row you're inserting is not a dup).
I noticed that was using a table scan, but in my testing, there's only a few
rows in the table, so it could be legitimate that the optimizer chose a
scan. Perhaps I should run a few life-size batches in the morning.
Thanks for the input.
--
Peace & happy computing,
Mike Labosh, MCSD
"Mr. McKittrick, after very careful consideration, I have
come to the conclusion that this new system SUCKS."
-- General Barringer, "War Games"