U might want to use this query select field1 from yourtable group by field1 having count(*) > 1
this would result all the duplicate row. If u want to list down all the duplicate records select * from yourtable where field1 in (select field1 from yourtable group by field1 having count(*) > 1) good luck -----Original Message----- From: Andy Ousterhout [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 10:24 AM To: CF-Talk Subject: RE: Primary Keys & Duplicate Values If all of your current fields have meaning, I recommend that you add a new field that is a meaningless number that you use as your key field. I've found that if I use a field with meaning as my key that I end up wanting to change that value. Exceptions might be code tables like ZIP Code and State Abbreviations where you have a reasonable expectation that the key (zip code or abbreviation) will never change. Andy -----Original Message----- From: Srimanta [mailto:[EMAIL PROTECTED]] Sent: Monday, October 07, 2002 4:43 AM To: CF-Talk Subject: OT: Primary Keys & Duplicate Values Hi, Once again its me. I have a table with 18000 records. There are three fields say field1, field2 and field3. There are no primary keys at the moment. I want to delegate field1 as the primary key in the modified table. When I try to create field1 as the primary key, an error is generated as there are duplicate values in the records in field1. How do I find which values are duplicate in field1. I cannot use the Find and replace function as I do not know which values to look for. Also manually it is impossible as there are too many records to search through. Is there a Cold Fusion custom tag or function or SQL syntax I can use? Any help will be much appreciated. Thanks Srimanta ----- Original Message ----- From: "Kola Oyedeji" <[EMAIL PROTECTED]> To: "CF-Talk" <[EMAIL PROTECTED]> Sent: Monday, October 07, 2002 9:38 PM Subject: RE: Variable locking > Hi > > I'm joining this thread late. Can I just confirm what you guys are > saying: In CFMX named locks should be used in place of scoped locks and > locks are only needed > When a possible race condition could occur? > > Thanks > > Kola > > -----Original Message----- > From: Sean A Corfield [mailto:[EMAIL PROTECTED]] > Sent: 04 October 2002 22:53 > To: CF-Talk > Subject: Re: Variable locking > > On Friday, Oct 4, 2002, at 12:07 US/Pacific, Gaulin, Mark wrote: > > Actually, that using NAME is not a better practice... the SCOPE > > attribute is > > safer and is also what MM support advised us to use (when applicable). > > Pre-MX. > > > Sure, the scope of a NAME-based lock will be tighter than using SCOPE, > > > but > > SCOPE will be safer and, as a bonus, you can use CF 5's (and prior) > > auto-checking for missing locks... > > Which is no longer available in MX because it is no longer needed. > > > Basically, "NAME" is older than "SCOPE", and SCOPE was added to > address > > issues that NAME cannot handle. > > SCOPE was added to resolve bugs in earlier releases of CF around the > shared scope memory corruption problems. That is no longer an issue in > CFMX. > > An Architect's View -- http://www.corfield.org/blog/ > > Macromedia DevCon 2002, October 27-30, Orlando, Florida > Architecting a New Internet Experience > Register today at http://www.macromedia.com/go/devcon2002 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~| Archives: http://www.houseoffusion.com/cf_lists/index.cfm?forumid=4 Subscription: http://www.houseoffusion.com/index.cfm?sidebar=lists&body=lists/cf_talk FAQ: http://www.thenetprofits.co.uk/coldfusion/faq Signup for the Fusion Authority news alert and keep up with the latest news in ColdFusion and related topics. http://www.fusionauthority.com/signup.cfm
