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

Yep, I had it that way (key and updateable fields) specifically for debugging purposes only

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

OK, the light goes on. The problem is in the SQL statement itself, not in the DBGetProp() statements. I should have RTFMessage the first time<g>.

Adjusting the SQL accordingly, the update conflict goes away. It's possible to put in an incorrect pointer for the StudentRatingID but it appears that I can handle that with a field or row level rule. Better yet, the front end will make sure the value is valid...

Thanks, I think I'm on my way...