>>> I snipped this because it was getting too long to scroll down to the new statements. Maybe we could all do this?
>>>So, you retrieve recordset by SQL, then index it (or you have index on view?) and use SEEK within it? It seems to me as double work.
>>
>>Ed,
>>
>>This is not double work, it is using a design approach that is scalable as opposed to one that is not scalable. I also use SELECT or P-Views to narrow down the record set and then will use seek within the VFP code to manuver within the sacled down record set. It is not double work and it is scalable, all I ahve to do is give the views a remote source and none of my code has to change, it all works in either situation.
>
>So you want to say that you never use SEEK against base tables?
>Answer this question, please.
>

I may SEEK(), or more often LOCATE, for UI operations once data sizes have gotten small enough to make sense in my application, by which time I'm dealing with a p-view or cursor, and I've limited the scope of the data in view or under edit to something that makes sense for a user-level transaction. I get to that point via SQL. I don't see a real advantage to having the full domain under edit for what should be an isolable, transactional operation.

If I'm munging about in the data by hand, or writing little QUAD things to deal with new, different and bizarre adventures in data processing, I use xBASE-y things all the time. I tend to put these things in SCAN...ENDSCAN constructs to create a fast WHILE condition so that I can filter on related things in the FOR clause. I don't have to think past "I know exactly how to do this one thing correctly" to knock out a 20 line one-shot (which I promptly run in the debugger, with a BEGIN TRANSACTION before I start and END TRANSACTION/ROLLOVER when I see what got hosed in the process. I end up having to ROLLOVER better than half the time on first try, or at least I'm glad I can where it would've worked, but it was taking a lot longer than I thought it should, so I stopped it and checked again that I didn't do something dumb.)

This tends to be code that is lucky to live past running it once or twice, often in the debugger under these circumstances. In reality, I'm still probably going to do things with SQL operations, because I'm probably going to be able to state what I want in a SQL statement first. This makes sense because I generally know what I want to do before I know how to do it. SQL delegates some of the process issues to the engine. I figure my time is worth more than the CPU's here.

I even BROWSE things at times.

I may have used SET FILTER, but I can't remember the last time I needed to.

If it's something I'm going to do alot, I probably should rework it to use the same data layer services as the rest of the application. I should probably think more about the problem, too.