Hi
I think dqmq has done a great job of describing the process Access performs during updates (note this is not the same as code from Access or even DML queries executed against the data).
Namely, when the row check for apparent concurrency issues is performed.
However I believe you when you say you're not doing anything else - and are just experiencing these issues as if they were entirely ethereal.
It would certainly seem to be the old Floating Point data type check.
When Access performs this row comparison, it checks every field. (A potentially relatively inefficient process in itself - but usually not a problem). However, floating point data types (specifically Float or Real) can cause inexact comparisons - even when the data does match in theory (i.e. it hasn't been changed by you or another user).
Since SQL Server 2000, the standard quick fix is to add a TimeStamp column to your table. Whether you employ this or not in your UI, Access will use it to determine concurrency access to that row (instead of checking each field) and that alone - circumventing the floating point issue.
There are fairly unlikely sideeffects of a TimeStamp column in Access (AFAIRC you'd need two subforms on the same parent with the same source table - inevitably pretty rare).
Don't forget to Refresh your table links once you've added the TimeStamp column to the SQL table.
Cheers.
