Erik,
Your responce below has saved us an unbelievable amount of time! Please give yourself a big "High Five"! We used the filter (!DELETED()) on the candidate keys which resolved numerous issues in many areas. All the tables we applied this to were small so optimization wasn't an issue. It is working great!
Thanks again for your help!
*-------------------------*

(These are views on underlying tables with trigger events using the "move record" method for updating.)

This is why I don't like Row buffering. You are implicitly issuing a TABLEUPDATE() without being able to check the results and handle any conflict. I recommend that even if you stick with Row Buffering, you incorporate a TABLEUPDATE() into your "move record" method, and do your checking there. Your problem is trying to figure out what happened after the fact, when you should be checking during the fact.

>I am also faced with the issue we touched on regarding the deleted records. *If I add a new record (to a view), delete it, and issue tableupdate - the record is marked for deletion in the underlying table. If I try to add it back, issue table update, RI sees it as a duplicate. The record is not in my view anymore, The message to the user is "Record blahblah is already in use."

I don't use candidate keys for this very reason. If you must enforce uniqueness at the table level, you can try puttinga candidate index with a filter for !DELETED().

INDEX ON MyField FOR !DELETED() CANDIDATE

(I think you can do that...) You would also want to create a regular index on that field, because filtered indexes are not optimizable.

Another alternative is to set the Candidate key value to something random or negative when you delete it.

FWIW, I usually handle this in the business object that handles the data. Before adding a record, I check (using an INDEXSEEK()) to see if the value already exists in another record. This way I don't rely on the mechanics and quirks of the database rules.

HTH