>>My main record choosing form has a feature packed grid based on a table. Some of the features of the grid are incremental search, and reordering of records when tabbing through the columns. These features obviously rely on indexes. A newly requested feature is to be able filter the contents of the grid to narrow the search. Because of the size of the table that the grid is based on, SET FILTER takes _forever_. I would like to be able to execute an SQL query, and change the recordsource of the grid to the resulting cursor. Issuing the query and changing the recordsource to the cursor are easy enough, but the indexing is posing a problem...
>
>Erik, a nice trick that has been mentioned here but IMHO hasn't been given due emphasis is the USE AGAIN technique with Cursors. This essentially makes them into read-write entities. You can add/delete index tags as you like. You can reindex as much as you need. You can add/delete records.
>
>The technique is:
>
>Select blah..blah... into Cursor MyCursor FROM MyDataSource && See BEWARE note below!
>Use (Dbf("MyCursor")) Again in 0 Alias MyRWCursor
>Use in Select("Mycursor")
>Select MyRWCursor
>
>Now MyRWCursor can be manipulated as if it were a table.
>
>Beware: if you intend to use the results of this query in subsequent queries (and also depending on how much VFP is able to optimize the original query), you might need to put NOFILTER after the FROM clause.

This was a really good technique in 2.6. But in VFP you don't know if the file returned by DBF() really exist on disk or is just in the memory. VFP doesn't guaranties the file really exist and my conclusion is (maybe wrong) that VFP writes the cursor to disk only when it doesn't have enough memory. (DBF() always returns a valid file name.)

There was a loooong thread about that a couple of months ago (started by Barbara Paltiel ?).

So, unfortunately, this technique doesn't work anymore.

Vlad