I understand the argument, in fact I and my colegues talked about how views work internally before I posted my first message. Hilmar made the same argument. We do not disagree here at all.
Understanding how the error came into being does not change the fact that it is an error.
The fact that other databases don't have the concept of deleted recrds does not change the fact that in VFP, which does have the concept, RECALL works incorrectly on updateable views.
Huge or not, that depends on design - I guess that may mean that either RECALL, or local updateable views are not used a lot. The part with DELETE/RECALL design of our system, dates almost 20 years back, and it will be hard to explain to 600 users that what they see as a feature, is no longer available because we use the advanced technique of local updateable views.
If the VFP help for RECALL specified that it does not work correctly with local updateable views we may have decided not to use views to update tables, or to start "educate" users that RECALL is bad and it should have never existed.

>I think that the argument Alexsey is making here is that for views to work on anything except Fox data, they need to translate RECALL in a view into an INSERT - SQL command, since many (most?) other databases have no concept of deleted records -- once you delete it, it's gone, and therefore must be re-inserted to be brought back.
>
>This behavior goes all the way back to VFP3, so it doesn't seem to have been a huge problem over the past 8 years or so.