>> NOt sure if why this might manifest itself as an update conflict, but I think I see at least one problem with your view definition- the field iStudentRatingID is pulled from the base table field StudentRating.iID, but it's UpdateName is set as StudentRating.iStudentRatingID. Does correcting this make the problem go away? <<

In toying with this for another hour, here's my findings:

1) The tModStamp field was automatically getting updated as a Rule based trigger on all my base tables. If a record was updated from the view, saved and then reupdated (without requerying), I could get a conflict that way. So I took tModStamp and tAddStamp out of my query for the moment.

2) Here's a subtle problem: The first record in my base table against my test query had an invalid primary key (pointer) into the StudentRating table. This would correctly show up as a NULL in the view. Fixed.

3) At the risk of looking foolish, I believe the UpdateName should be ClientService.iStudentRatingID. If I change the UpdateName to reflect StudentRating.iID, I can change the primary key of the StudentRating table without conflict -- but that's not what I want<g>.

It's getting late and I'll study this further tomorrow, pending any additional suggestions you may have. Things have somewhat clarified: If the iStudentRatingID has a valid pointer into the StudentRating table, updates on the other fields works, no problem. If the iStudentRatingID field carries a NULL beforehand, I will get an update conflict no matter what -- even if I put in a valid pointer for this field.