Microsoft Knowledge Base Email Alertz

(280730) - You receive the following write conflict error when you try to update records in a linked SQL Server table: This record has been changed by another user since you started editing it. If you save the record, you will overwrite the changes the other...

Search KbAlertz

Advanced Search

Receive Microsoft Knowledge Base articles by E-Mail?

Every night we scan the Microsoft Knowledge Base. If technologies you're interested in are updated, we'll send you an e-mail. You only get one e-mail a day, and only when new articles are added.

Click here to create a
FREE account
Already have an account?
[Click here to Login]











Microsoft Knowledge Base Article

This article contents is Microsoft Copyrighted material.
©2005-©2007 Microsoft Corporation. All rights reserved. Terms of Use | Trademarks

Article ID: 280730 - Last Review: July 29, 2004 - Revision: 2.1

You may receive write conflict errors when you update records of a linked SQL Server table in Access 2000

This article was previously published under Q280730
Advanced: Requires expert coding, interoperability, and multiuser skills.

This article applies only to a Microsoft Access database (.mdb).

For a Microsoft Access 97 version of this article, see 278696  (http://kbalertz.com/Feedback.aspx?kbNumber=278696/EN-US/ ) .

SYMPTOMS

You receive the following write conflict error when you try to update records in a linked SQL Server table:
This record has been changed by another user since you started editing it. If you save the record, you will overwrite the changes the other user made.

Copying the changes to the clipboard will let you look at the values the other user entered, and then paste your changes back in if you decide to make changes.
You are then given the following options: Save Record, Copy to Clipboard, or Drop Changes.

CAUSE

Access is creating Null bit fields, which causes a type mismatch.

or

The linked table is using fields defined as floating point data type (i.e. Real). This data type allows for storing "floating point" number data. When the edited record is passed to SQL Server, if both engines see the data in these fields as having the identical value, there is no problem. However, because of the "rounding" algorithms used by JET and SQL Server, the actual value compared may be different. Since JET has to review each field and see if there are any concurrency issues, when JET compares the number it sees (in the "Real" data type field) to that value stored in SQL Server, if it does not match exactly the record is assumed to have been changed and a Write Conflict occurs.

RESOLUTION

To resolve the problem with bit data type, do one of the following:
  • Using SQL Server, open the table in Design view, and assign a default value of 0 (zero) on all bit fields.

    NOTE: With this option, you must update records that were entered before this change was made. See the next item for more information.

  • Using SQL Server, run an Update Transact-SQL statement against the table, and set all bit fields that have a value of Null to a new value of 0 or 1.
  • Using SQL Server, change the bit fields to some other data type, such as int or tinyint.
  • Using SQL Server, add a timestamp field to the table.
  • Use a Microsoft Access project (*.adp) instead of an Access database (*.mdb).

To resolve the problem with floating point data types, do one of the following:
  • Add a timestamp column to the SQL table. (JET will then use only this field to see if the record has been updated.)
  • Modify the data type that is in SQL Server to a non-floating point data type (for example, Decimal).
  • Run an Update Query to update the record. You must do this instead of relying on the recordset update.
NOTE: If you make changes to the data types in the SQL Server tables, relink the tables in Microsoft Access.

MORE INFORMATION

Steps to Reproduce Behavior

The following steps assume that you have an understanding of how to create tables in SQL Server, and that you are familiar with certain SQL Server tools such as Enterprise Manager.

Also assumed is that you are aware of how to create File, User, and System Data Source Names (DSN), and how to use a DSN to link a table to a Microsoft Access 2000 database.
  1. In Microsoft SQL Server 7.0 or later, add a new table to the Pubs sample database that has the following table structure:
    Collapse this tableExpand this table
    Column NameData TypeLengthAllow Nulls
    fldIDint4<unchecked>
    fldBitbit1<checked>
    fldDescripvarchar50<checked>

  2. Make the following Column property assignments to the fldID field:
       Identity: Yes
       Identity Seed: 1
       Identity Increment: 1
    					
  3. Set the fldID field as the primary key, and then close and save the table as Table1.
  4. Insert the following records into the Table1 table:
    Collapse this tableExpand this table
    fldIDfldBitfldDescrip
    11Record #1
    2<NULL>Record #2
    30Record #3
    41Record #4

  5. Close the table, and then create a User DSN that points to your SQL Server.
  6. Open any Access 2000 database, and then link the Table1 table from the Pubs database into your database.
  7. Change the description of Record #1 to Record #0. Note that you can save your change.
  8. Try to change the description of Record #2 to Record #1. Note that you receive an error when you try to save your change.

APPLIES TO
  • Microsoft Access 2000 Standard Edition
Keywords: 
kberrmsg kbdatabase kbprb kbdesign KB280730
       

Community Feedback System

Very often, it takes hours to solve a problem. Very often, you've looked high and low, and have tried a lot of solutions. When you finally found it, chances are, it was because someone else helped you. Here's your chance to give back. Use our community feedback tool to let others know what worked for you and what didn't.

Please also understand that the community feedback system is not warranted to be correct, it's simply a system that we've built to let people try and help each other. If something in a feedback response doesn't make sense to you, or you're not comfortable making changes that the feedback talks about (like registry edits), please consult a professional.

Thank you for using kbAlertz.com Feedback System.

-- Scott Cate

Chris Howard Report As Irrelevant  
Written: 3/3/2005 9:54 AM
This was just what I needed. Adding the timestamp field to my SQL Server table fixed the problem. Thanks!

Bob Report As Irrelevant  
Written: 3/23/2007 2:33 PM
Great advice - right on the money - I would never have guessed that it was a floating point routind error - especially because it was only triggered when I changed a Memo field, not when I changed any other data field in the record. (Wierd, huh?)

HaydnV Report As Irrelevant  
Written: 8/3/2008 11:28 PM
Great Advice. This really helped although in my case I've found this problem happens with the SQL 'money' data type not matching the Jet 'currency' type. I change the money type to decimal, relink and the write conflict goes away.

GC Report As Irrelevant  
Written: 7/16/2009 9:55 PM
The first article that half explains WHY we need a timestamp field!