Peter Norman wrote: > You have explained why it was necessary to do this. But it might be helpful > to change the terminology employed since the issue is not strictly one of > complexity but of the number of potential hits. Not really! It is the number of records read from the database to come up with a hit. The complexity bears no relation to the number of hits that the search will produce, only to the number of records returned in the first pass by the best index. > A complex search implies, at least to me, that it is one that seeks to match > multiple criteria. Such a search might be anticipated to require more cpu > time. Whereas searching for a single but common surname is not complex. But > the number of hits also takes up too much cpu time. Yet the current default > explanation implies that it is searches lacking a surname that will cause > problems. I see the problem, and would welcome a better word (searches that we describe as too complex are I/O bound rather than CPU bound though. The complexity is the number of disk reads that will be required). To be honest, I plucked "complexity" out of the air when implementing this. The original term used (and still used within the code) was "cost". Of course using anything on those lines would cause even more confusion. -- Dave Mayall

Good day all. How about: This search cannot be run as it is too wide-ranging to complete within available time and computing resources. Or In order for your search to be completed please be more specific about the range of years and/or the event and/or the Registration Districts selected. Or Available computing resources mean your search can only be completed by limiting your criteria of date range, event and/or Registration District. Or We would like to help but you must be more specific with your criteria in order for the search to be run. I'm sure there are some better phrases out there but I hope these suggestions help. Best wishes Anne Cruise [email protected] Dave Mayall wrote: > > > To be honest, I plucked "complexity" out of the air when implementing this. > The original term used (and still used within the code) was "cost". Of course > using anything on those lines would cause even more confusion.