RE: Using SQL to check for duplicate records

 The part I missed mostly is that there's no assurance that the fields to be
checked are key fields.  In that case the RPG solution won't be of any use.
 
 
 
---------------------------------------------------------
Booth Martin   http://www.MartinVT.com
Booth@xxxxxxxxxxxx
---------------------------------------------------------
 
-------Original Message-------
 
From: Midrange Systems Technical Discussion
Date: 1/9/2004 4:15:51 PM
To: midrange-l@xxxxxxxxxxxx
Subject: RE: Using SQL to check for duplicate records
 
Booth:
 
That's where count(*) comes into it. Rob's example shows that a second
SELECT statement must also be executed. In effect, a new temporary table is
created on the fly by that SELECT. That table contains one row for each key
that's duplicated. When the primary SELECT executes, each row is tested
against the temporary table to see if he's dealing with a duplicated key or
not. If he is, he simply prints the key and the RRN. The temporary table
fulfills almost the same function as lookahead would -- it simply verifies
duplication for each row at the time the row is read.
 
If the temporary table happens to be very large, conceivably you could have
space problems. Unlikely enough that I wouldn't worry about it unless I was
dangerously short on space and expected a lot of duplicates.
 
Tom
 
midrange-l-request@xxxxxxxxxxxx wrote:
 
>   9. RE: Using SQL to check for duplicate records (Booth Martin)
>
>One question I have about the SQL solution is about printing the results.
>When/how does one print the RRN of all duplicate records using only SQL?
>
>-------Original Message-------
>
>In SQL, just getting count(*) for the groups could take a chunk of
>processing. I'm not sure it could be any more efficient in any other
>language.
 
 
--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone  253-872-7788 x313
Fax    253-872-7904
http://www.powertech.com