>All,
>
>Within my current discussion with John Petersen about the differences between SQL and xBase data manipulation commands, the following came in mind:
>
>In a lot of situations we are more or less forced to use local (SQL) views. These views are created out of executing a SQL select command and a handfull off rules concerning the update of data. Sometimes I experience the execution of these SQL commands when loading a dataenvironment as a real pain because it hurts performance pretty much.
>
>As in the referred discussion I did come to the conclusion that SQL is very often doing a bad job. Therefore I want to have something like a local VFP view (CREATE VFP VIEW command).
>
>These views should be made out of tables related with eachother with the SET RELATION command and filtered with the SET FILTER command. Within a the dialog you should be able to select the fields you want to include with the view. In fact we can already do this with manually setup the table hierarchy (SET RELATION and a SET FILTER) and issue a BROWSE FIELDS command.
>
>I want to take this approach one step furter by saying that, that specific view (SEE SET VIEW command) configuration is permanently stored within a local VFP view, but with the propeties of a normal view, so it must be able to:
>
>- Give this view a name
>- can simply say USE myVFPview ALIAS myalias (without showing the underlying hierarchy)
>- can involve this view within any VFP DML operation (maybe except for ZAP, PACK etc.) like in a SQL - SELECT command.
>
>This would give the following advantages over SQL queries:
>- A huge performance gain over a SQL view as there is no query to be executed (only loading the view and underlying hierachy made out of SET RELATION and SET FILTER and USE 'table' ORDER MyTag commands) in many but not all situations
>- Using the indexes of the undelying tables (so you don't have to create one for yourself after the query) even within transactions
>- You can use all available locking strategies including NONE, pessimistic row and tablebuffering
>- Validation of the record van field validation rules are automaticly inherited (because you're working on the underlying tables directly)
>
>There are also some disadvantages.
>- Like in a hierarchy there is one current (the parent table) table, Only FOR clauses involving these fields in these tables are rushmore optimizable, like:
>REPLACE field WITH somevalue FOR parenttable.field = someothervalue : is rushmore optimizable
>REPLACE field WITH somevalue FOR childtable.field = someothervalue : is rushmore not optimizable
>- You can't use group by and dictinct clauses
>
>To emulate inner, left and right joins you might have to use SET SKIP TO, FOR (NOT) EOF("Childtable") filters within the VFP view.
>
>What do ya think. Wouldn't this be nice ?
>
>
>Walter,

I guess your point is that the problem is not that we do not have some ready-to-use tool. The problem is that some ways are hidden, and a developer should not be blind dealing with data.
Personally, I saw on many occasions that Xbase native approach is far superior in terms of performance than blind SQL-statement, and correspondingly I use it when it's the case. I believe you do the same, and this is correct way, and obviously this distinction has nothing to do with OO or not-OO arguments. It's about data.
Sorry, if I interpreted your message wrong way.