Thanks Ed for your help,

>You've basically created an insoluble problem, since the HAVING clause requires the initial selection to take place before the HAVING clause can filter the desired result set. In order to do the GROUP BY, you have to pull across every single record to create the result set, since no filtering takes place in the WHERE clause (there is no WHERE clause, so every single record is considered as a part of the result set.)

I understand from what you are saying that I cannot test for duplicates whitout tranferring all the records over the "wire", because the test occurs in the HAVING clause and that clause is tested last.

>Rushmore optimization isn't going to help here. Your best bet would be to rethink the problem so that a summary record that kept a count of records matching the key for summarization exited, which could be used as a filter in a WHERE clause, which takes place before the set of records needed to perform the GROUP by is performed, rather than the filtering occuring in the HAVING clause, which occurs only after the GROUP BY operation occurs, reducing the number of records passed over the wire.

I don't understand your suggestion, it seems to me that I will have the same problem since I want to know only if I have duplicates. I want to narrow the spot where the duplicates are created. Also I can remove all the duplicated records and wait and see when and where they will come up.

Also and very important to me, my rnis users are not really rnis users. They connect to the server via a pcanywhere connection to a station on a 10Bt network. So it will take 10 seconds for the station to retrieve the data when they come in and out of the application. Which can occur ten times per hour.

Thanks again Ed.