>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, because as far as I know, you can only index tables and views. Is the only way to do this to put the results into a table and then use and index the table? If so, where (physically) should the table be stored? I would also need to come up with a random naming convention for the table in case of multiple instances of the form. Am I approaching this from
>the right angle? If so, how could I prevent multiple same-named copies of the temp table? If not, how the heck do I go about avoiding FILTER for this one? Any insight is appreciated.
>
>Erik

You can index an SQL cursor, but only once. If you need a different index, you will have to re-query the data and then create a new index tag.
Remember that SQL cursors are READ ONLY, so you can NOT edit them.
If you have any way of creating a one-to-many relationship, that will produce your best performance.