Well, some points are too obvious to be discussed even, but why do you put SEEK to 'prohibited' list? Do you want to look for one/few record(s) in 10 millions using SELECT-SQL? It's about the same as using rockets for sparrow hunting.

>Walter,
>
>I have to agree with all that Jim has said here and would like to add the following point:
>
>While it is more convenient, in the short-run, to use xBase features such as SEEK, SET FILTER and so on, it is crtical for developers to be more than proficient with SQL even if the data will never move to a back-end server.
>
>I'm advocating a discipline here much as OOP is a discipline. Granted, at first it's not easy (set theory is not easy), but any problem to which an SQL solution is found only adds to our skill set.
>
>For example, I had a problem this week which could have been easily solved with SET RELATION TO blah, SET SKIP TO blah, and SEEK(blah,blah). I had to find another solution due to the fact that I exclusively use SQL and p-views for all my work - it's part of my framework. While it WAS NOT easy, I found a solution that came as a result of a logical thought process which is demanded from set theory and which I never would have learned otherwise.
>
>The only xBase I use is with the views themselves - SCAN/ENDSCAN, LOCATE, GOTO, SKIP, BOF(), EOF() - that's it. So far, I have never had a performance issue - which, in most cases, are due to bad design anyway.
>
>The bottom line is to have a skill set (a discipline) that can be used with C/S as well as non-C/S applications. Developers who settle for mediocrity with things like SET FILTER, SET RELATION TO blah will eventually experience PAIN when the day comes for a robust C/S application because they won't have the skills.
>
>
>
>>Jim,
>>
>>>>I've seen arguments about using p-views here, but I've got serious problems with that. P-views cannot replace all functionality of SET FILTER:
>>
>>>P-views can't use buffermodes none and pessimistic row and table buffering
>>
>>>None is unavailable because it is impossible to get a view to directly update its source "on the fly". Pessimistic locking is non existatnt in the sense of client-server systems. The equivalent functionality can be provided for the pessimistic stuff.
>>
>>>You can't refresh the p-view when you've got modifications in the view.
>>
>>>So what? You can use the view to provide the set of records and then relate it into the table and directly edit the table. However the whole design will go ot hell in a handbasket once the system moves to C/S. Why would I want to purposely design an application today that cannot go to C/S without the data handling being completely rewritten?
>>
>>You're talking about C/S systems here, from my POV this is humbug. There are lot's of FP/VFP are not designed to ever be upsized to C/S. Upsizing is a difficult job when you don't want to make consessions at the UI side, especially in cases where xBase equivalents are far faster and more flexible than SQL equivalents. I want to use native VFP tables, even in a C/S environment (use replication) where I can add indices for rushmore and ordering tables, where I can set relations to avoid JOINS at the server side (remember the xBase join example I gave you), where i want to browse a large table just to get an impression of whats in it (so not adressing all records). How do I explain the user that she can't freely browse trough a million record table (with the help of a search mechanism, like interactive search) because then the SQL-server would be overloaded (because of the multple joins) or resulting in bad performance ? Do I have to say, this can't be done because I want to avoid this
>>programming style ?
>>
>>>You can't use the original indexes of the source table. Though you're able to create temp indexes, they'll give a problem within transactions.
>>>
>>>As you said, you can create indexes on the view if you need them. I find that 9 times out of 10 the data only needs to be in one order so I just use the ORDER BY clause of the view and let it go at that.
>>
>>I want the user to have the posibility to order the table on a few important items. Using indexes in P-views result in bad performance and can cause problems in transactions.
>>
>>>P-views generates a temp table, consuming CPU cycles, disk I/O and memory, giving serious performance problems with larger tables.
>>>
>>>Hog wash! I have tested views against direct file processing and the data retreival may be slower, the same, or faster than the xBase equivalent depending on what is being done. However, in the tests I have run and the tests others have run the difference when there is one is usually very small.
>>
>>See the reply to Ed Rauh regarding aggregrated views.
>>
>>You don't seem to understand what i'm trying to say: If I got a million table in a grid and only adress a few records in it, you'll NOT experience any performance problems. When using P-views you've got to execute the query, maybe rebuild the indices, and also adress only these few records the user might browse to (thus can't be predetermined). There is a huge difference in the two approaches.
>>
>>Practical example: A user wants to see if some articles are in stock. The users launches the article form. The form shows a grid with articles of which articles are know in the system, via an incremental search he can search the article in various way, as he types the grid locates the first matching articles, giving the user feedback if he has located the article. He selects the right article presses enter and the form displays the second page with detail data.
>>
>>In a CS environment it is practically impossible to list all million articles in the grid in the same way as the previous example. You've got to only download the data you need making a selection at forehand. An incremental search in the way of the former example is fairly impossible to construct, You've got to make consessions here. The user will never be as free to browse trough the table. You might say, BIG DEAL. yes, too me it is. I'm on the standpoint that the user is the boss and i've got to make him able to achieve his goal in a for him/her a convienient way. p-view fall short here in terms of implementation issues.
>>
>>
>>>I assume that you never read Malissa Dunn's book for the 1st The Pros Talk Fox series on SQL. She compapred xBase equivalent syntax to every SQL she demonstrated and published the performance times. Her findings bear out what I just said. The number of differences are equal to both approaches, sometimes xBase is faster and sometimes SQL is faster but in all of them the difference was minor. There were only a handful of situations where either of them was considerably faster than the other and those were also evenly divided between the two approaches.
>>
>>I didn't read the book, but I know what you're aming for, If processing records, i'm with you, in most cases there will be no big difference in performance.
>>
>>I'm talking about issues where it's likely to occur that the user only wants to adress very few records in this whole table (thus not processing). For example I can use a big table over a WAN connection and issue a browse for only looking what's in it. If i decide I want to look further into the table I might press pagedown and another windows of data is downloaded from the server. But it is not likely to occur that I want to browse trough the whole table.
>>
>>I C/S enviroments I'll want to download the whole table before I can do a browse. I admit you can use batchmodes, but this is also limiting and complex to manage.
>>
>>My issue is that I can open a table, set a filter and let the user decide to which records to access. As long as the record is not accessed the filter will not create a delay.
>>
>>Walter,