Is there a technique to identify reason for duplicates sql

I have a query that joins 4 tables and i have duplicates.
I know what causes the duplicates but...
is there a technique that will key you in on the offending data.
jamesmetcalf74Asked:
Who is Participating?
 
Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
Causes, no, SQL Server tables don't really store any auditing information on how/why/specifically what bad query JOINs/specifically what ETL jobs ran more than once/under what Zodiac sign rows were INSERTed into it, unless a developer either rolls their own auditing or impliment something like change tracing or change data capture.

BUT

Eyeballeth thy article SQL Server Delete Duplicate Rows Solutions for a T-SQL code and image-rich tutorial on how to detect and deal with duplicates.
0
 
Dustin SaundersDirector of OperationsCommented:
Generally, I'll start removing joins until I see the dupes disappear.  Then you can see what table is causing the problem, and go select info from that table to see where the cartesian product is coming from.
0
 
jamesmetcalf74Author Commented:
I will taketh thyne advice.  you are loyal dukes of the kingdom of MSFT SQL
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

 
Jim HornMicrosoft SQL Server Developer, Architect, and AuthorCommented:
Bless you my child.  Go forth and sin some more..
0
 
jamesmetcalf74Author Commented:
haha
thanks guys
0
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
If all tables are in 3rd normal form then I would say you're missing some column joining.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.