This typically happens when two or more forms try to update the same record. The same is true if you have a sub form on a form and both the main form and the subform are trying to modify the same record in the same table. Access thinks of the main form and the form in the subform as two different "users".

If one of those doesn't cover it, then we'd need to see your form/query in design view along with any code that could be modifying the data.

Please report back what you find Martin, I'm curious. Also, please tell us what record locking settings you are using and where.

I opened the file.  Logged on as usual.  Opened the Person form for my personal record.  Clicked on a button "Person CIS" and changed the passport number.  See screenshot.  I have done nothing else before that.
The form is based on a query where the primary table is tblpersoncis where fkPerson is joined to pkParty in tblparty.  The first passport number is in tblparty, not in tblpersoncis.

I noticed the Person form was still open so i closed the d/b and logged on again and opened the fromPersonCIS directly without going through the Person form.  But I still got the same error when I tried to update the passport number

I see this one a lot, even in my own databases sometimes. Where you've got an event that runs when the record opens and maybe makes the record dirty. And then something else, perhaps an SQL statement that you're running, tries to also update the same record while it's still dirty. So you have to make sure that you refresh the record after each change if you're trying to make background changes. This usually only happens with complicated code. I've actually got a whole video on this coming out soon. So stay tuned. In the mean time see Record Locks

fromPersonCIS should read frmPersonCIS.

I haven't used a SQL query as the primary source for a form's data, only in combo boxes of the form.
Is it possible that the form source query makes the change from the form and updates the table (via refresh), and then the form saving/closing sees to make a change again, but isn't smart enough to know the change was from its own source that was already updated?  It sounds confusing, but this kind of thing is common when an intermediary is used, in this case the source query, unless the application plans ahead for this in its internal structure. This is similar to the problem I've hit when one form using a global module contaminates the persistent data from another form's call to the same global module. The Access team has overlooked a lot of these kinds of situations.

If you are using relationships and cascading updates, I've seen Access get very confused in the whole record locking area. On my system, in my experience working in tables, it just pops up a lock error and then hangs any further work on the record. Your experience might be a different manifestation of this problem.

Thanks, Richard and Thomas. I shall check whether my form is trying to update something on load or current that I haven't thought of