That works as long as the user is constantly querying looking at data, making adjustments and doing more queries. My idea is to let the user sort on ANY column in the grid simply by clicking on it. I would have to create too many indexes to do that (close to 240).

>Once you get datat selected into a cursor, you can make the cursor RW and index it.
>
>select ... into cursor crsTemp
>use dbf() agin in 0 crsMyCursor
>use
>select crsMyCursor
>index on ... tag ...
>
>When you close the cursor, the CDX is removed from disk as well.
>
>>Actually it breaks above 9.
>>
>>My reasons for this is simply to get everything into one table so that I can display this information to a user who may want to filter on any of those fields and see them in a grid. Unfortunately, I as of yet, have not found a way to sort a grid based on a foreign Id in a child table other than with an SQL statement with an ORDER BY clause.
>>
>>>Technically, a LEFT or RIGHT JOIN creates a sub-query in order to select matched and unmatched records. According to VFP help, you can only have 2 for each query level. However, I do have a view that uses LEFT JOIN on the same level 4 times [joining a total of 5 tables]. And, I am sure I have others like this. I suggest you start smaller and work upward to see at what point the SELECT breaks [how many LEFT JOINS actually break the code].
>>>
>>>I am sure you have good reason, but why would you want matched and unmatched records from so many tables? IMHO, this is too many records and too much data to try to deal with. Is this for some kind of statistical analyses? Just curious.