Receiving Write Conflict Error

Why do I receive a write conflict error below when I'm the only user working
on this form and useing this reocrd? The application is my local drive and
the back end
database is SQL Server 2000.

Write Conflict.
This record has been changed by another user since you started
editing it. If you have saved the record, you will overwrite the changes
the user made.

Copying the changes to the clipboard will let you look at the values
the other user entered, and the paster your changes back if you
decide to make changes.

Tom LeBold wrote:
Why do I receive a write conflict error below when I'm the only user
working on this form and useing this reocrd? The application is my
local drive and the back end
database is SQL Server 2000.

Write Conflict.
This record has been changed by another user since you started
editing it. If you have saved the record, you will overwrite the
changes the user made.

Copying the changes to the clipboard will let you look at the values
the other user entered, and the paster your changes back if you
decide to make changes.

With a SQL Server back end this is usally fixed by adding a Timesatamp field
to the table on the server.

In a record being updated in an ODBC link Access will compare every field in
the edit buffer to every field in the same record on the server to see if
anything has changed on the server since your edit session began. If it
sees any field that doens;t match then you get that message.

With certain datatypes (text for example) this field-by-field comparison can
get fooled into thinking the data doesn't match even when no changes have
occured. The reason a Timestamp column solves this is because in a table
having a Timestamp field each Timestamp value is updated with a database
unique value any time the record is altered. The ODBC driver knows this and
will compare only the Timestamp values to look for changes instead of
looking at every field. Not only does it solve the problem, but it is more
efficient as well, particularly for tables with lots of fields.

--
Rick Brandt, Microsoft Access MVP
Email (as appropriate) to...
RBrandt at Hunter dot com