It is simply unreasonable to expect that a given problem does not stem from a fault in the design.

>Hi Hilmar,
>
>I know you are trying to help, but I must say I get a bit frustrated when a discussion about a bug ends up as a discussion about application design or how much better would be a C/S database.
>I suspected the same things about how RECALL from updateable views works, but let's not mix too many things and lose sight of the problem...
>
>Why is this dangerous?
>- You have a duplicate key in the base table - this in itself should be enough, don't you think so? (and I don't think any C/S database does that).
>- Subsequent tableupdates for that key generate the warning: "The key... is not unique".
>- VFP allows you to recall the deleted duplicates
>- Updating the table using a view, updates all duplicates (but the user gets the warning every time)
>- Updating the table without a view, allows recalling duplicates and/or editing any one of them, you can end up with some updates in one record and some in another.
>
>Regardless of how updateable views work internally, RECALL sould not add duplicates.
>If it does, then it should be documented.
>And again, if it works that way updatable views, from my pov are useless.
>
>Thanks.
>
>>I think this is because the view internally generates standard SQL commands, commands that work both against DBF tables, and against a database server which will probably not even have the concept of deleted records.
>>
>>For triggers and referential integrity, the situation is similar: when you RECALL a record, it is treated like a newly-inserted record. That is, the Insert Trigger gets executed. Quite logical, in this case.
>>
>>I suggest you just treat deleted records as deleted. One benefit is that thus, your application is more scalable: you won't need to redesign for C/S.
>>
>>Why exactly do you consider it a problem, or dangerous, if a new record is added, instead of re-using the old one?
>>