>So you want to say that you never use SEEK against base tables?
>Answer this question, please.


I don't actually want to say anything in particular.

I do recommend that p-views are a more scalable method of dealing with narrowing down a record set than SET FILTER is.

I do not dismiss the SEEK command as something that should be avoided. As to whether a SEEK is executed against a native table or a cursor from some other source should not make any difference.

However, for other reasons, directly using native tables in VFP is NOT scalable. Now keep in mind NOT scalable does not mean "should never be done" or that it is bad, it simply means that the technique is not scalable and if the system ever needs to be scaled to some other platform there will be a major redesign issue at hand.

If the crystal ball says "This app will never need to go intranet or internet or client/server then there is no problem with using native tables directly."

My problem with doing that is that my crystal ball says something else, "This application will either be retired and replaced or it will be capable of scaling to the intranet, internet, and client/server arenas because the business is going to grow and the industry and technology are going to advance and the client is going to want to compete." Because that is what my crystal ball says, I am NOT going to do anything that I know will be a problem with scalability. I know that one cannot design today for everything that may occur later, but one can avoid those design decisions that are known today to limit scalability.

From what I see in the world today drawing a conclusion that any particular application will never go internet is a real "head in the sand" point of view. Hell, I can order my pizza from the local pizzeria over the web.