>No, the VD is not the advantage to views. The advantage to views it...
>
>1. Useing a view creates a read-write buffered cursor.

So does SPT and ADO....

>2. When a tableupdate() is issued C++ speed code builds the required updates and passed them to the back end.
>

This makes exception handling very difficult. That is what I wan't as a developer...less control...< s >... BTW, the speed advantage you speak of is a myth.. SP's will give the best performance... Then again, speed should not be the number 1 concern. Issues of security and scalebility should rank higher..

>3. Remote view updates are automatically wrapped in a transaction.

That is only 2 lines of code in a SP... Not a big deal...

>4. You write much less code due to item 1 & 2.

And you cede more control.. You should know by now that it is rare code that is automatically generated is all you need.. And, if you are smart in the way you build tools, it takes no time at all... Rod and I have apps where a DB might have 400-500 stored procedures... The development process took no longer. In fact, it may have been shorter because we ended up not dealing with the headaches associated with RV's.

Ask yourself Bob, how much time do you spend working around problems associated with RV's?

>5. This is one of the best ways to create a C/S and Local Table version of your product with very little code differences.
>

The same version of an app that can work seamlessly with local data and remote data is a myth... It does not work. There are too many stories of pain here to illustrate that fact...


>Although I have since learned that hard coding ANY SQL, RV, SPT or SP is the WRONG WRONG WRONG way to do it, and am working on a VFP Persistence framework which will eliminate the need to write SQL code.
>

Can't wait to see that.....