Ed,

>The single biggest advantage to SQL over xBASE implementations is that SQL specifies what you want, where xBASE describes the process to follow to get it. SQL deals with a description of the desired result. The choice of how to satisfy the requirement is left to the data engine; and a backend can do things like examine key distributions, system contention, and implement alternative index strategies to enhance performance and take advantage of data patterns and organizations that I didn't anticipate.
>
>We have different philosophies here - the user should be able to address his needs either through data specification or by the scope of the task at hand. I find that drilldown is well-received by my users rather than exhaustive data sets which must be narrowed progressively, with a corresponding increase in retrieval cost as filters are refined. YMMV. My users don't like hundreds of items in view at once, much less thousands or millions, and generally have narrowed the scope of the data domain in question, or don't want to deal in detail with the domain.

Well stated.

Use the proper tool for the job, regardless of what it is.

Besidex, there's the practical notion of NOT sending excess and unwanted data over the network. By using SQL's feature set regarding view and so forth you do the work remotely where it can be done most efficiently.

Best,

DD