The query below selects the rows from table_1 which do not exist in table_2 based on values in the 4 columns. The mismatch could be due to one or more columns.
I would like to extend the query to tell me which column(s) had the mismatched values, either by showing the column name or its value. I can do this in a cursor but prefer to do it in a set based operation if possible.
SELECT i.agent ,
i.agency ,
i.customer ,
i.Company
FROM table_1 AS i
WHERE NOT EXISTS ( SELECT p.agent ,
p.agency ,
p.customer ,
p.Company
FROM table_2 AS p
WHERE i.Agent = p.Agent
AND i.agency = p.Agency
AND i.customer = p.customer
AND i.Company = p.Company )
Update:
I guess this needs more refinement. Let’s add that 3 out of 4 columns need to match.
You can simplify this problem drastically if you require that certain columns do match, or at least start with some expectations of which columns should match. In other words, instead of looking at this as a non-matching problem, redefine it as a partial matching problem.
Let’s say you expect
agentandagencyto match, butcustomerandcompanymight not. This isn’t too difficult:If you want to check for other partial matches, just reorder the columns. Instead of joining on
agentandagency, join onagentandcustomer, or whatever.If you only expect a few different kinds of partial matches, you can write a few different queries similar to the one above and put them together with a
UNION(orUNION ALLif you don’t mind duplicates). In other words:Now if you’re looking to get every conceivable mismatch, then this is quickly going to get out of control, so you might want to adapt a more heuristic method, and search for partial matches that match at least a certain number of columns (say 3). Then you can restrict the obnoxiousness to at most the number of columns you have to compare:
Now, having said all this, there’s one thing I’m wondering…
These two data tables aren’t, perchance, sequentially related, are they? As in, the 3rd row in table1 always maps to the 3rd row in table 2, but may not match all columns? It’s a shot in the dark, but if that is indeed the case, then we could make this way simpler. Otherwise, the last query here should probably do what you want without becoming too much of an unmaintainable mess.
Note that performance is likely going to stink for all of these queries. Hopefully your data sets aren’t too large. AFAIK there is no easy way to really optimize this kind of thing.