>Hi Mike,
>
>I looked at your article in FPA, and I have a very similar routine myself which I call when I wish to zap a view. The main difference is that I didn't set Sendupdates to .F. before zapping, because I was under the impression (maybe incorrectly) that zap does not delete the corresponding backend records because there are no view records with key fields to match any backend records. This contrasts with DELETE ALL which flags records for deletion and the corresponding backend records are eventually deleted. It hasn't caused any problems for me yet - have I been lucky?
>
>I have just run the following code...
>lcParameter = 123
>USE MyView && sendupdates=.T.
>=REQUERY() && selects 3 records
>=CURSORSETPROP('BUFFERING',3)
>ZAP
>=CURSORSETPROP('BUFFERING',5)
>APPEND BLANK
>* Load some data here
>=TABLEUPDATE(.T.) && update all records
>
>Looking at the back-end, none of the original records have been deleted, and the new record has been appended.
>
>For safety, I will insert the switching off/on of Sendupdates - I just hope no records have been accidentally deleted by my omission (none have been reported yet ;-))
>
>Your (or anyone else's) thoughts would be appreciated.

I want a combination of safety, speed, flexibility (control).

I believe there never was any danger of the records being deleted, but I look at it like this. We are well advised to subclass a framework's classes before building anything. That's a safe thing to do. If the framework vendor were to release a textbox that had behavior we don't like, we would have a place to fix it.

Now it's very unlikely that VFP would change ZAP to have it also delete the records in the base table, but it certainly let's me sleep better knowing I've already ORDERED it NOT to send any updates.