Hi Vlad,

Well using surrogate keys requires extra indexes too and that is a very common practise.

And since VFP 6 you *can* define a filter on a primary key programatically.

True, this may not be the wisest practise but while VFP continues to deal with deleted records in the (only) way it does now this is a legitimate usage in many cases to easily avoid primary key violation errors involving deleted records. This is the benefit.

Cheers,

JimN


>Hi!
>
>2 indexes - larger CDX - more data to transfer through network - slower application.
>
>What is benefit for adding deleted() filter to the primary key tag? Once I tried to gendbc.prg such database made by other developer. After making PRG I discovered that I had to make filters manually because there are no way to do this for primary key tags programmatically (you can read this in the comments inside of the gendbc tool). So, why messing with it?
>
>I remember, this was already discussed somewhere at the http://fox.wikis.com site.
>
>>SNIP
>>>
>>>You should avoid filters in other indexes. I know there are people that recommend to filter indexe by deleted(), however, this is completely wrong because such indexes are not used in the optimization. Just the deleted() as an index expression is fine.
>>>
>>SNIP
>>
>>Hi Vlad,
>>
>>It is not "completely" wrong - any time that I have seen that advice it was also accompanied by a recommendation to *ALSO* make another TAG on the same expression *without* the filter.
>>And the filter was virtually always suggested for the PRIMARY key or a CANDIDATE key. That is, not willy-nilly for many TAGs.
>>
>>Cheers,
>>
>>JimN