>>> 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.

You should also be able to correct this by ensuring that the timestamp field is not updatable from the view, and making your view use only the PK in the WHERE clause as opposed to all modified fields.

>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>.

The UpdateName property is what's used to correlate a view field with its base table fields in the UPDATE or INSERT statement. If the field in question is the PK of the updatable table, and it is set to updatable, setting it to a field name that does not exist should result in an error. If the field is not set to updatable, you might not.