>Doug,
>
> Actually, every thing about that original SQL statement was "optimizable". Trouble was, doing a six way join overloaded VFP's ability to optimize anything. It was being forced to create massive temporary tables. Breaking the single SQL statement down into "bite sized chunks" allowed VFP to accomplish everything in memory. (having 1/2 GIG memory didn't hurt!)
>
>Dragan was on to something when he suggested slicing off just the key values your query needs into a cursor or temporary table.
>

Actually I was just doing the first step, i.e. reducing the number of records to work with, which means I got a short recordset from a long table. Your idea of doing a narrow set as well (i.e. reducing the number of columns) is the next step. I really didn't need to do that in the cases I described, because the process was already dramatically sped up. But you do have a point there; actually, copying (or SQLselecting) just a few key fields is something I've done back in 286 days when the need arose. Well, the datasets we're operating with today are also relatively huge (measured by the machine's horsepower) so this is a way to outsmart not only Rushmore, but probably any data server as well.