Error saving record, write conflict?

[Denise2020]

I have never come across this before. The text in a long text field in our database shows #Deleted for two records. When trying to retype what was lost, an error message comes up. It is in Swedish but it says something along the lines of "Your changes cannot be saved because another user has updated the field". However, there is only an OK button, no option to save changes to clipboard like you see in a normal write conflict error. The #Deleted remains and cannot be modified.

The table is linked from a backend and each user has a copy of the front end on their own computers. I come across the same error whether I try to modify the field in the form or even directly into the table (I thought it might be a form error, but it apparently is not). I even tried writing into the table directly into a copy of the backend. Other than those two, other records are unaffected and can be modified and saved without any error. My apologies if I leave out information that you need, I am unsure as to what else you might need to know to help with this issue.

What could cause this and how do we fix the problem? Thanks in advance!

 

[arnelgp]

maybe related to this error:
after January update #deleted error when inserting records into - Microsoft Community

 

[Denise2020]

Interesting. The affected field in this case is a long text field and not an identity field/number and not on an SQL server. As a workaround I will have my coworker create a new record and see if we can delete those that seem corrupted. However, the idea that information loss can happen without knowing why or when is disturbing.

 

[Pat Hartman]

The usual method is to do this with one or more append queries. Select all the rows before the first corrupted row and append them to a new table. Skip the corrupted record. Then select the next bunch and append. Skip the corrupted record. Then select the next bunch and append, etc. In the select queries, include the autonumberID so child records will not be orphaned. An append query is the only method available for actually specifying a value for an autonumber. If you don't have dependent tables, then you can ignore the autonumbers and just let Access generate new ones. If there are dependent tables, you will have to remove the RI before recovering the data.

 

[gemma-the-husky]

It might be a data corruption.

Another possibility is it's a real error
Often the "another user" is yourself, though, as you might have the same record open in 2 different forms, and you are thereby causing the error.

 

[Petr Danes]

I have run into this with records in a BE that do not have a unique identifier. It's a very misleading error message, but the gist is that there is no reliable way to identify the record being delivered by the FE to the BE without such an identifier, so the BE refuses to accept it. No idea why it does not deliver a sensible error message, but I have always solved this by adding a unique identifier to the recordset being retrieved from the BE.