Hi Walter

Interesting idea. I wonder if the problem demonstrated with tablebuffering and recno() would appear here? By that I mean, if I enable tablebuffering, and delete an existing record, would it correctly update that tag?

>Hi mike,
>
>Why not using an index on NOT DELETED() Then at least you can find the first deleted and non deleted very quickly without having to worry about rushmore performance problems since the NOT operater prevents optimization.
>
>Walter,
>
>>Hi Fabio
>>
>>Is INDEX ON .T. better than INDEX ON "A"?
>>
>>I find no difference in size of CDX or time to INDEX ON. Is there speed difference with SEEK?
>>
>>>
>>>Fabio,
>>>
>>>I guess you´re right. This indeed would make it simpler. However I´m not sure on how many Visual FoxPro developers are waiting for this feature and if the VFPT should implement this.
>>>
>>>In other words, I don´t think many developers would regard your problem with the non-optimizable GO BOTTOM as such a big problem that it should be addressed in the next version at the cost of some other equally time consuming feature request.
>>>
>>>By no means I´m saying that you´re wrong. In fact you do have a valid point up here. The only question is if it is important enough to make it for Visual FoxPro.Next
>>>
>>>Walter,
>>>
>>>
>>>But this is only one of uses of ORDER 0 DESCENDING.
>>>
>>>In fact tagno 0 is supported in a table relation, then a minimum of coherence in the design imposed the descending of the recno.
>>>
>>>Currently, if I want to turn upside down the order of one workarea I must create an index, and this has many limits.
>>>
>>>Example: load one local/remote/spt/ca view with a ORDER BY and I want to turn upside down it;
>>>now i must requery or do a INDEX ON .T. ... DESCENDING, but if i have a tablebuffering i cannot do it.
>>>
>>>However i think you have reason, this you will not never come implemented into VFP.