Thanks to all the responses to my question. I didn't realise this was such a divisive issue! :-)

>In many cases SPT will keep working just fine after changes to a table while a >view will not. This means less maintenance with SPT. I still use both, but I >prefer less maintenance.

Since views must be contained in a database and the database contains the full definition of the view it is possible when an app. starts to use DBGETPROP() and rebuild the view despite any back end changes. The only problem with this is that if the fields that are used in the view have their names changed or are removed then you are in deep brown poo-poo. However, any developer/DBA that does this deserves to be forced to watch 48 hours of Mr Springer. And its not such a big deal anyway because all you have to do is issue a new .DBC and every thing is hunky dory again.

>Won't VFP then update all those records you appened to the view if the view is >updateable. Seems like a lot of work. I just use SPT for ad-hoc queries, then >when the user selects a record to edit I bring that record down using a view >parameterized on the PK.

If you USE the view with NOUPDATE then it shouldn't

>With a view, VFP generates the SPT on the fly. In my experience this adds a >little bit of overhead. The query that gets sent is the same so you'll add the >same amount of overhead no matter how many records the view returns.

This seems to me to be the only reason for using SPT except for the fact that, as you say, the overhead is caused by VFP create the SPT to fire back at the server and not the actual retrieval time. My view on this is that the application would have to be run on a *SERIOUSLY* slow PC for this to be an issue.

Another point: Does SPT have and advantages over views when it comes to transactions/multi-user updates? I doubt it but opinions are welcome.

JohnH