Click here to monitor SSC
SQLServerCentral is supported by Redgate
 
Log in  ::  Register  ::  Not logged in
 
 
 


Using EXCEPT to Determine Row Differences


Using EXCEPT to Determine Row Differences

Author
Message
M. Douglas Bowan
M. Douglas Bowan
Valued Member
Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)

Group: General Forum Members
Points: 63 Visits: 89
Comments posted to this topic are about the item Using EXCEPT to Determine Row Differences
nick.latocha
nick.latocha
SSC-Enthusiastic
SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)

Group: General Forum Members
Points: 111 Visits: 265
Something to note about EXCEPT is that it is a DISTINCT Query and does not compare duplicate rows. Any suggestions on how you would get around this?
M. Douglas Bowan
M. Douglas Bowan
Valued Member
Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)

Group: General Forum Members
Points: 63 Visits: 89
Where I have been using this is to keep read-only data synchronized between two areas by their primary key, so I do not currently have a scenario like this.

If I was keeping a full history of everything synchronized to date that this might be similar to what you describe.

Could you explain further?
Arno Ho
Arno Ho
SSC Eights!
SSC Eights! (983 reputation)SSC Eights! (983 reputation)SSC Eights! (983 reputation)SSC Eights! (983 reputation)SSC Eights! (983 reputation)SSC Eights! (983 reputation)SSC Eights! (983 reputation)SSC Eights! (983 reputation)

Group: General Forum Members
Points: 983 Visits: 63
hello,

The join between #source and #Target in the SELECT .... EXCEPT is not essential
You can obtain the same result with a best cost
SELECT [S].[ID]
, [S].[Item]
, [S].[Price]
, [S].[OrderDate]
, [S].[Units]
, [S].[ShipmentDate]
FROM [Source] [S]
EXCEPT
SELECT [T].[ID]
, [T].[Item]
, [T].[Price]
, [T].[OrderDate]
, [T].[Units]
, [T].[ShipmentDate]
FROM [Target] [T]
;

Am I wrong?
Arnaud
nick.latocha
nick.latocha
SSC-Enthusiastic
SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)SSC-Enthusiastic (111 reputation)

Group: General Forum Members
Points: 111 Visits: 265
Lets say we have a reconciliation against a 3rd party vendor where we submit sales to them.

There is a chance we can submit the same sale twice by accident. We would then only have 1 sale in our system but the vendor would see 2 sales. How do we use EXCEPT to reconcile these kinds of differences?
simon.c.jones
simon.c.jones
Grasshopper
Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)Grasshopper (19 reputation)

Group: General Forum Members
Points: 19 Visits: 22
I agree with Old Hand. I tried the comparison both with INNER JOINs and without. I got the same result in both instances.
andrea.onah
andrea.onah
Grasshopper
Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)Grasshopper (21 reputation)

Group: General Forum Members
Points: 21 Visits: 50
I have created, inserted the values and run the query as posted in this article and it produces the same result as

SELECT [S].[ID]
, [S].[Item]
, [S].[Price]
, [S].[OrderDate]
, [S].[Units]
, [S].[ShipmentDate]
FROM [#Source] [S]

EXCEPT
SELECT [T].[ID]
, [T].[Item]
, [T].[Price]
, [T].[OrderDate]
, [T].[Units]
, [T].[ShipmentDate]
FROM [#Target] [T]

Still therefore trying to understand the use of the join
David McKinney
David McKinney
SSC Eights!
SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)

Group: General Forum Members
Points: 909 Visits: 2090
the join is to restrict the comparison to those cases where you have the same key values present in both source and value - and are looking for differences (rather than present in one and not in another.)

Agreed that with the test data provided, this is not very apparent. if you add a row to the source table with an ID which is not present in the Target table, then you'll see the effect of the join.
David McKinney
David McKinney
SSC Eights!
SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)SSC Eights! (909 reputation)

Group: General Forum Members
Points: 909 Visits: 2090
you can use UNION also to do something similar. In this case, it returns both rows when there's a difference.

SELECT   *
FROM (SELECT *
, count(1) OVER (PARTITION BY ID) AS versions
FROM (SELECT *
FROM #Source AS ss
UNION
SELECT *
FROM #Target AS ss
) x
) y
WHERE versions <> 1


M. Douglas Bowan
M. Douglas Bowan
Valued Member
Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)Valued Member (63 reputation)

Group: General Forum Members
Points: 63 Visits: 89
Without the join, the except statement would also return rows in the source that do not exist in the target as well as those that exist (by id) in both sets but are different.

What I needed was to determine differences between rows that exist between both sets, but have differences.

Having a series of tables with 100, 200+ columns to compare is asking for human error, especially when nulls need to be taken into account.
Go


Permissions

You can't post new topics.
You can't post topic replies.
You can't post new polls.
You can't post replies to polls.
You can't edit your own topics.
You can't delete your own topics.
You can't edit other topics.
You can't delete other topics.
You can't edit your own posts.
You can't edit other posts.
You can't delete your own posts.
You can't delete other posts.
You can't post events.
You can't edit your own events.
You can't edit other events.
You can't delete your own events.
You can't delete other events.
You can't send private messages.
You can't send emails.
You can read topics.
You can't vote in polls.
You can't upload attachments.
You can download attachments.
You can't post HTML code.
You can't edit HTML code.
You can't post IFCode.
You can't post JavaScript.
You can post emoticons.
You can't post or upload images.

Select a forum

































































































































































SQLServerCentral


Search