>My table is aprox 38,000 records. If I browse the table it takes a fraction of a second to view. If I create a local view with out any filters it takes several seconds to view. I was just wandering how to keep the speed up. I only need to filter out a small percentage of records at any one time.

You're being fooled by the power of the browse window.

What you see is not all of the records. The browse window only brings back enough to present the results to the user. If you scroll down fast enough, you will encounter a fetch back to the server, and some lag time.

One of my cardinal rules for client-server apps is to only fetch the records you need, and NEVER - NOT EVER - let the user access the entire data set. You must force them to narrow down the number of records that they are interested in.

Sometimes this takes some creative thought. For example, I often have to visually scan tables for particular patterns of data, and correct those (I seem to get stuck doing a lot of data imports). It is much, much faster to construct a view that does the search for me, than look for these manually (not to mention being more accurate).

My point is that you need to think about what you let the user have access to Indexes are not always the answer, and can in fact cost you (in update performance). Make them do some kind of select first, and results will come back must faster. This is true in VFP as well as SQL, as Rushmore doesn't kick in until you have some type of WHERE clause (or other selective operation) specified.