Hi Mike,

Yep, STN way back when.

Ya know, there's no denying that it could have been caching at play though my sense is still that it wasn't THE factor...

You may remember that one person would report a slowness and several people would have a look-see. I'm almost sure that other runs would have been done by others on their own workstations. I seem to recall doing just that at my own workstation on a few occasions (and I trusted the report so didn't just re-run and then try different things)
And I'd bet that these were ALL network-access queries.

Keep in mind, too, that we'd be working in DOS and that our bigger workstations were ones with 32 meg. I think developers had workstations of 8 meg back then with 486-33 or 486-66. Also don't forget 10bps network at that time.
The server was a PI-66mhz with 256MB RAM but it did have a Storageworks RAID5 array (dual SCSI) which was simply marvellous.

As DBA back then the TAG on DELETED finally sunk in and I did make certain that every table had one.

So it remains mysterious to me.

cheers and thanks for having me dredge up some good memories.

>Hi Jim
>
>I think I was working with you at the time. STN right? It didn't occur to me until reading said article, but caching may have been playing with our minds. Consider that we probably ran a query on a table with no deleted tag, added the tag and then ran it again. Caching would certainly impact there. If it was done on a local drive versus the LAN, that too would have skewed the results towards having a DELETED() tag.
>
>Based on something Walter Meester said in another thread though, if VFP is only examining the CDX tag keys for records that match a condition, then it must be examining most keys since most records are NOT deleted.
>
>>Hi Greg,
>>
>>I just want to add the observations of one very stubborn person as regards this issue (of TAG on DELETED() being good or not)...
>>
>>I SURELY AGREE that today a TAG on DELETED() is most likely a BAD IDEA.
>>And the FPA Advisor referred to 'shows' categorically that the same is found in FPD (or maybe FPW) 2.6.
>>Yet I just cannot get out of my mind a few experiences where, back in FPD2.5/2.6 days, the simple addition of a TAG on DELETED() did turn a very slow SQL query into one that was lightning fast.
>>
>>I notice, too, that VFP9 (Europa) has something that also addresses optimizing when there is a TAG on DELETED(). Let's hope that it is good AND survives to implementation.
>>
>>regards
>>
>>>Walter,
>>>
>>>That's interesting because AccPac Pro Series has deleted() indexes on practically every table. Could it be because many installations never pack out tables for months and months on end?
>>>
>>>I'm definitely not disagreeing with your advice, I just want to think about it before ripping all the Deleted() indexes out of Pro Series.
>>>
>>>Greg
>>>
>>>>Hi martin,
>>>>
>>>>>Just wanted to point out that my own experience showed me that it is not plain record count what slow things down, but having too many deleted records. The delay at USEing the table can be prevented with proper indexes on deleted(), as it is caused basically because a scan is needed to find the first non-deleted record.
>>>>
>>>>A very, VERY dangerous advice. an INDEX ON DELETED() will cause you headaches on large tables since for every rushmore optimizable expression about the whole index tag needs to travel the network before even finding one record. A simple browse statement can take several seconds to execute esspecially on slower networks.
>>>>
>>>>A simple USE could take several seconds as well (though I could not quickly replicate this behaviour in VFP8). It is way better to ensure that no deleted records exists at the top of your table (depending on the index order you set initially with the use command).
>>>>
>>>>An index on deleted() almost never is a good idea. This is a proven fact and there even is an article in Advisor handling this specific problem. So please, please remember: Throw away your indexes on deleted()...
>>>>
>>>>Walter,