>>That is why this work around almost always works. There is no update conflict detected so the update procedes uninterrupted.
>
>I think I'm getting it. Thanks for your patience, Mark. I hate having a cold -- feels like I'm slogging through molasses.
>
>Now, by changing it to this key field only thing, I've made it work... but if I'm understanding it right, I've made it more likely that people will be overwriting each other. Because the key field is never going to change, even if two people are working on the same record at the same time, right? I wonder if it would be useful to do something with a timestamp and use that keyfield and timestamp option.
>
>Also, this is a great workaround, but I still don't understand why I would have the original problem. If the field is null in Access, I wonder why I was getting blank data in fields instead of null. I guess it was because it was blank and not null that changing it made me have the update conflict, right? Because the value in the table (blank) didn't match the value I was submitting (nonblank), right? And it didn't do that with the nulls becuase Fox just knows that nulls are not blanks and doesn't treat them the same? But still, wonder why something that is null in Access would come across blank sometimes and null sometimes in Fox?

I don't know enough about Access to give an answer on this. So, I deal with Access as little as possible [only once actually]. In VFP, I will use the NVL() function in my Select-SQL field list to convert fields that accept nulls to blanks.

select nvl(mytable.field1, space(field1_fieldwidth)) as Field1, ...

If my users are serious about data integrity and want a full blown app, I won't allow the data to reside in Access. I put it in Oracle or VFP. IMHO, Access data is for personal DBs or very small groups of people sharing an MDB with nothing but Access as the front-end.