The DELETED() index gets better in over-the-wire operations as the proportion of deleted records increases. If there is no over-the-wire penalty then yes, the index on DELETED() will always help. Otherwise, it's cost/benefit is definitely subject to experimentation for verification.

**--** Steve



>Dear Steve:
>
>I thought the original wisdom of using the deleted index was to speed things up? Hmm... You are right though, if you are using Foxpro tables, instead of a client server enviroment, then the indexes must come over.
>
>This may account for the slow down we have been experiencing starting up our application on NT based networks with optimistic buffering enabled. Thanks for the thoughts
>
>Regards,
>
>Jim Smith
>>Hi Gord,
>>
>>I've seen this movie before < s >.
>>
>>From what you describe, it clearly looks like the bottleneck is, as typical, the network.
>>
>>I'm sure that if you activate a network monitoring program (like, for example NetMon.EXE) you'll see tens, hundreds, or thousands of megabytes of data going over the wire leading to the workstation. I've seen seemingly bullet-fast local queries dog to a minute or minutes over a network because of hundreds of megabytes of unanticipated network traffic that's obscured by bus traffic when the query is local.
>>
>>The seminal reference to this is an article by Chris Probst in the May 1999 Foxpro Advisor article, "Rushmore Queries: Less is More". Perhaps more imediately handy are these links which discuss related issues:
>> http://fox.wikis.com/wc.dll?Wiki~NonDiscriminatingIndex
>> http://fox.wikis.com/wc.dll?Wiki~BigSystemPerformanceAndVisualFoxPro
>> http://fox.wikis.com/wc.dll?Wiki~UnderstandingRushmore
>>
>>If I were to guess, I would suggest removing any indexes on DELETED() that apply to the major tables involved in the save process. An index on DELETED() is typically a non-discriminating index, all of which Rushmore sucks over the wire for little or no benefit.
>>
>>So in a word, identify and kill (DELETE TAG ...) the most non-discriminating indexes on your larger tables.
>>
>>**--** Steve
>>
>>
>>>I have created an executable and distributed it to the customer. Upon installation, the customer complains about how painfully slow the application is. I am thinking... 2 seconds to perform multiple saves and return control is slow??? What the reality is... at the customer site it will take close to 30 or more seconds to perform a save.
>>>
>>>First thing you think of is, poorly written app, not using Rushmore? I have more than 6 years experience using FoxPro, so my familiarity with the language can be ruled out.
>>>
>>>Details...
>>>
>>>1. The app was developed on a 1.2ghz machine which performs multiple saves in sub 2 second range and returns to the user.
>>>
>>>2. Tested database on machine in a different shop 833mhz, same result.
>>>
>>>3. Tested database on MS Network and app on 833mhz machine in the different shop. Server was over 10 blocks away (Seriously!), same 2 second save.
>>>
>>>4. Tested database and app on Clients workstation 1.6 ghz alone, same 2 second save.
>>>
>>>5. Tested database on Clients network and App on Clients workstation 1.6ghz, 30 to 40 seconds to save.
>>>
>>>
>>>Any ideas... My client has not gotten back to me if they are using Norton AntiVirus or not.