>>I'm using pessimistic buffering, and if I move off the record (to look for a duplicate value) without doing tableupdate, it gives me the error. Yesterday in the conference, someone gave me an idea to unlink the case # object from its control source until it's saved. I think I may do that. Also, Nancy Folsom gave me a good ERROR procedure which I may use in the future.
>>
>>Thanx,
>>JR
>
>I ran into something similar. I had a parent and child table, both indexed by an integer. I used views on a form and in the child view I made both the integer number and a second field (the one I sorted on and needed to be unique) the key fields. When I executed a TABLEUPDATE on the child I got the 'Uniqueness violated" error msg, because the integer value was the same in all the child table records.


Oops!
I should have said that in the child table, since the integer number was the only key and the parent-child relationship was 1-to-many, I made a second field in the view part of the view key. That eliminated the "uniiqueness violated" error but led to another error when I attempted to delete a parent key. With cascade delete on the base tables the presence of the two-field key in the child view confused the RI-Delete code and left the child records as orphans. I got around that by doing the delete on the parent table itself.
Jerry