Thank you Tamar for your reply.

Having the weekend to ponder on why our system started to slow down, it was tracked to a routine that was inserting a record into a buffered table with approx 1.2 million records. We found that if an index of DELETED() was created, the process speeded up considerable. Not sure exactly why this made such a big difference but it did. The decission was to bring down the system for the evening and add the DELETED() index and as long as we were at it, we decided to add the same DELETED() index to other large tables in the other 9 DBC's in the applications. When we brought everything up again on Friday life was wonderful until we started to get complaints from all our users on accessing one tab on pageframe on the main form. In a panic effort we tried to determine why this was occurring and found by putting a NOFILTER clause in a simple query against a very large table that would produce anywhere from 0 to less than 10 records brought our system back up to speed.

Having all weekend to ponder, I see where this query is used in a grid where the operator can select different rows to present related information. In this case the query records are used as control sources in other controls(mainly textboxes) for presentation only. Since each record of the query can contain different facility types, in the AfterRowChange of the grid a method is called to refresh the multiple textboxes with related information. Some of these textbox controls are switch visiblilty if they are related to the particular record on the grid cursor and refreshed. This leads me to assume that by refreshing these other controls they were triggering repeated query's of the grid cursor?? By putting the NOFILTER clause in, it certainly would not cause this to happen. In the course of the day, we found a couple other area's where performance took a hit after we added the DELTED() index to large tables. Our conclusion was to keep the DELTED() indexs and add the NOFILTER clause to query's where we show issues. Interesting enough, some of the spots had nothing to do with grids, but we did see where a pattern of textbox controls sources were used for resulting query's.

Our concern is what issues will result by quickly adding the NOFILTER clause to query's where it possibly will not be necessary?

I thank you agian for your reply and help

Ron

>>Hence we are finding that we do need a DELETED Index and by putting NOFILTER in the query has gained us the most bennefits.
>>
>>Question I have is what is the draw back of putting a NOFILTER in all of our query's? Realizing that in should not be necessary, but it the quickest way to make performance issues.
>>
>
>Your results don't make sense to me. NOFILTER should slow a query down or have no effect; I can't see how it would speed a query up.
>
>Oh, wait. Is it the query itself that got faster or the use of the result cursor in, say, a grid? That would improve with NOFILTEr.
>
>What NOFILTER does is prevent VFP from taking an optimization shortcut. When a query involves a single table, and the field list contains only fields of the original table (no expressions), and the WHERE clause is fully optimizable, VFP simply filters the original table rather than creating a new file on disk. Since disk I/O is one of the slowest things around, this speeds up the query considerably.
>
>However, when you use the cursor, what you actually have is a filtered table. Grids don't handle that very well.
>
>To answer the question you asked, on a query involving more than one table, NOFILTER has no effect at all.
>
>As for DELETED() and SET DELETED, check this topic: http://fox.wikis.com/wc.dll?Wiki~NonDiscriminatingIndex~VFP
>
>Tamar