Jim;
Thank you for your reply. I responded to Tamar with what I assume was causing our issues and we found that the easiest corrective measures were to put NOFILTER clauses in query's where performance was taking a hit.

Your explanation gives me a sigh of relief that the NOFILTER clause will cause us much of an issue in the future. As time is allowed, i am sure we will evalutate our use of a query result for control sources in controls. Seems to be the common problem, however, when ever a grid is used, the performance is greatly effected.

Thanks again for your repy.

Ron
>Hi Ronald,
>
>I've read TamarG's reply.
>
>I think there's more to it, but first I want to point out that if you SET DELETED OFF then your result set will include deleted records BUT they will NOT be marked as deleted in the result set. You likely do not want that.
>
>TamarG is right that VFP takes a shortcut, but that does come at a terrible price in later logic that TO ME, simply isn't worth the price. My rate of hair loss slowed considerably once NOFILTER was added to the language!
>
>As regards the more to it...
>I *suspect* that buffering is having some impact on what you are seeing, especially as regards the improvement observed with NOFILTER.
>WithOUT NOFILTER the same buffer for the table itself is used for the result set too. With NOFILTER you get a separate buffer for the result set.
>In addition TamarG mentions that NOFILTER involves disk I/O, which surely is the slowest part of the system. That is 100% correct IF there is an eventual need to use actual disk I/O. But in fact the chances are good (depending on the size of the result set of course) that there will be no need for actual disk I/O - it will all stay cached (buffered) in storage. This is most especially likely in the case of a Select-SQL result set which, by definition is EXCLUSIVE USE. When any file is exclusive use the operating system is free to buffer it to its heart's content in the local RAM because there are no outsiders interested in the latest state of the data held in that file (because they don't even know it exists).
>
>In summary, the use of NOFILTER *can* result in real disk I/O but the chances are that it will not. And even when it does it will be in large chunks that can involve several megabytes.
>
>I'd STRONGLY recommend that you ALWAYS USE NOFILTER.
>
>Jim
>
>>We experienced a slowdown of an application and found that by putting in a DELETED() index the performance gained. However, in doing so other area's where a select was being done on this table the performance really slowed down.
>>
>>An attempt was to set deleted off before the query and then reset afterwards did make some improvement.
>>
>>Alternate attemp was to put NOFILTER in the query and it made a vast difference.
>>
>>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.
>>
>>Any comments would be greatly appreciated