>I understand that PViews are usually faster and stabler with grids than SET FILTER, but I'm telling you there not a good alternative to doing a Seek(), they have to be predefined in a database, ect.

The main issue is scalability - I want all my apps to be able to scale to a back-end server painlessly using a combination of remote paramterized views and SPT for the look-ups. As such, I cannot use SEEK() unless I create temp indexes on the views - not very elegant and not really neccessary. I'll take any minor speed tradeoffs giving up the use of SEEK() any day for gains in scalability. My customers pay extra for this ;>)

As a result, I haven't used SEEK(), SET FILTER, SET RELATION, SET SKIP (did I leave one out) in almost two years - nor is it a part of my framework.

>>>>Being well disciplined in SQL allows you to create C/S and non-C/S apps with VFP, but not both.
>>Typo.
>
>Oh, Whats it supposed to be?

Being well disciplined in SQL allows you to create both C/S and non-C/S apps with VFP, but not both without the SQL.

>Im calm, just trying to have a technical debate/argument/conversation. I am curious why you dodged that question too, but it doesn't matter.

I wasn't trying to dodge anything. I was trying to show that, while SEEK() is extemely fast, any incremental benefits of it's use is far out weighed by the benefits of alternative schemas.

Hey, I love SEEK - Iv'e been using it ever since my friend Jeb Long designed the original command for dBase. In fact, we had an argument about this a few months ago - he hates SQL. He hates it so much that he trying to develop an xBase Server - but you didn't hear it from me. ;>)