Linked Access DB “record has been changed by anoth

Question

I'm maintaining a multiuser Access 2000 DB linked to an MSSQL2000 database, not written by me.

The database design is very poor, so you'll have to bear with me.

On the 'Customer' form there's a 'Customer_ID' field that by default needs to get the next available customer ID, but the user has the option of overriding this choice with an existing customer ID.

Now, the Customer_ID field is not the PK of the Customer table. It's also not unique.

If a customer calls twice to submit a job, the table will get two records, each with the same customer information, and the same customer ID.

If a user creates a new ticket, Access does a quick lookup for the next available customer ID and fills it in. But it doesn't save the record. Obviously a problem - two users editing have to keep track of each others' work so they don't dupe up a customer ID.

So I want to modify the "new record" button so it saves the ticket right after creating a new one.

Problem is, when I test the change, I get "This record has been changed by another user since you started editing it".

Definitely no other users on the DB. The 'other user' was presumably my forced save.

Any ideas?

Answer 1

I also had same problem. I was trying to update in a table using Spring MVC and hibernate. In my case the version column in the table contains a value more than 1( i.e. 3) however the update information in my update query had version value 1.

Answer 2

Our problems was that the access front end was trying to save an int (yes/no) into a mssql bit (0/1) field. Changing the mssql database to int fields worked like a charm.

Answer 3

I just came accross another situation that generates this error. In a mysql table I had two date columns which had initially default value '0000-00-00'. Later it was changed to default NULL but many rows kept the value '0000-00-00'. I had to manually reset the values to NULL to stop the error.

It took a lot of time to figure out what was trigering the error, HTH someone else.

Answer 4

I would keep track of whether the user has overridden the new customer_id with a value of their own. If they haven't, then your app should be able to check for a duplicate right before saving and just self-increment again, and the user didn't mind taking the default. Maybe even some indicator to the user that you had to automatically choose a different value.

Answer 5

The error you're getting usually happens when:

1. you are editing a record in a form and the form is dirty (i.e., edits not saved),

AND

2. you run code that uses DAO or ADO to run SQL to update the same record.

To Jet, that's two "users", because it's two different edit operations. The underlying table has been updated by the SQL update, while the data in the form buffer is now out of date.

The usual solution is to force a save before running the SQL update:

  If Me.Dirty Then
     Me.Dirty = False
  End If
  [run your SQL update here]

But if you're using forms to edit the record, you ought to do all updates in the form, rather than resorting to SQL to do the update.

The situation you describe with generating your own sequence ought to be done in this fashion:

1. user hits NEW RECORD button.

2. calc next sequence value and store it in a variable.

3. insert a new record with that sequence value via a SQL INSERT.

4a. if your form is bound to all the records in the table, requery the data editing form (assuming the NEW RECORD button is on the form where users edit the data), and use bookmark navigation to move to the new record with the sequence value that you stored in the variable in step 2.

4b. If your form is not bound to all the records (as it shouldn't be if it's a well-designed database), you would just change the recordsource of the form to load only the new record.

Another alternative is to avoid the SQL INSERT and requery (or resetting the recordsource) and simply add a new record in the existing form, set the sequence field to the new value and immediately save the record.

The key point is that for this to work in a multi-user environment, the record has to be saved just as soon as the sequence value is assigned to it -- you can't leave the record hanging out there unsaved, because that means the identical sequence value is available to other users, which is just asking for a disaster.

Answer 6

This error can also be thrown if the SQL Server table contains a datetime2 column (in my case with the default value of sysdatetime()). Changing the datatype back to datetime default current_timestamp stops the error.