Just a quick thought. Have you checked those "DUP's" by comparing them with SLEN(Column_Name_Whatever)? I ask just in case they have trailing blanks/ASCII 32's or any other "hidden" characters, such as a control code to which Rbase doesn't "react".
My $0.02, Steve in Memphis -----Original Message----- From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of John Croson Sent: Friday, July 18, 2008 1:50pm 13:50 To: RBASE-L Mailing List Subject: [RBASE-L] - RE: Interesting behavior Thanks, Bob. That's the odd thing: they ARE dups. I think I'm going to have to dump this, and start over again. Thank GOD we keep a copy of all flat files we import... On Fri, Jul 18, 2008 at 1:42 PM, Castanaro, Bob <[EMAIL PROTECTED]> wrote: > I believe Delete duplicates will only delete if all the column values are dups. You have to use the delete duplicates using col1 col2 col3, etc to compare just those columns. > It also runs MUCH faster with indexes on those columns, because it has to go through each row individually and compare all these text values. Very time consuming. > > -----Original Message----- > From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of John Croson > Sent: Friday, July 18, 2008 2:21 PM > To: RBASE-L Mailing List > Subject: [RBASE-L] - Interesting behavior > > I'm noticing a bizarre behavior when I issue the DELETE DUPILICATE > with no column references. > > Where there should clearly be a match, the rows are not deleted. Any ideas? > > BTW, I've compared rows of data by hand, and have found duplicate > information in each field, so I know I'm not going batty...YET. > > -- > John Croson > [EMAIL PROTECTED] > http://pcnorb.blogspot.com/ > http://pcnorb.homelinux.org/ > > > -- John Croson [EMAIL PROTECTED] http://pcnorb.blogspot.com/ http://pcnorb.homelinux.org/
