🚀 go-pugleaf

In article <36D1B713.8E3E747B@nospam.mcbsys.com>, Mark Berry politely 
paraphrased ...
> 
> Thanks, that works great on my sample data and makes sense to my simple
> mind (select the good ones, then NOT them).  It also doesn't seem to
> create the huge temporary tables created by a JOIN.  I was actually
> testing with "SELECT *" in place of "DELETE", since I want to give the
> user the opportunity to review the records before deleting them.
> 
> The problem comes when run on production-size tables.  I've got five
> tables to check.  The master is about 4000 records; the child tables
> range from 4000 to 55,000.  I finally killed the process after an hour. 
> It CPU-bound, I think--NT Task Manager showed it running at 81% of my
> Pentium Pro 200 the whole time, and I didn't hear a lot of disk
> swapping.
---
No idea, are there _simple_ indexes for the involved fields?

> I'm beginning to wonder if it wouldn't be simpler to just loop through
> each table and do a findKey() based on each record.  WDYT?
---
That's also a possibility. 
-- 
Romain Strieff [TeamB]
Please read this newsgroup guide below before 
posting on the private Inprise newsgroups.
http://www.inprise.com/newsgroups/guide.html
--