>> The first thing you need to understand is that a RV IS an SPT cursor. It is just wrapped in this thing you call a view. so - to make those commands work - you need to do the SAME THING the view is doing - the things you have to set properties for on the view - namely - a lot of cursorsetprop() stuff i.e. keyfieldlist, sendupdates, updatenamelist, wheretype etc.
>

>I realize that. Again, as you said, you're talking about a lot of code.

but once in framework - you never see it

>However, SQL is a readonly properly on an SPT cursor. Don't you need to have the SQL statement to do an update?

no - whether a view or regular SPT cursor - the TableUpdate() command goes through and concatenates a string based on the fields that have changed and per all the settings you've set up (wheretype, etc.). It then passes it on to the backend as an "Update mytable set myfield = ..." statement through SPT. I would imagine that internally, it is doing some kind of GetFldState() iteration to build the string. if you're doing table buffering - it just does them one at a time.

I promise this works! I have a sophisticated vertical market app based on this and I'm sure my sites would be screaming at me if it didn't! <bg>

I think part of the fascination with RVs is that people think there is some magic to them. There isn't. What "magic" there is is mostly in the tableupdate()command and the cursor itself - not in the fact that it was filled from a view!

Tx,