By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
464,760 Members | 1,182 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 464,760 IT Pros & Developers. It's quick & easy.

SQL-Server <-> A97 Write conflict error!

P: n/a
I have a few tables in SQL Server 2000 and a small Access 97 that has
linked tables used to insert/update/delete into SQL Server 2k tables.

Everything works fine except Updating one of these table through
Access, I get
"Write conflict error" which basicaly says since you have updated
this record some other user has updated it. I know for sure this is
not True, becuase noone else has access t this database.
This does not happen to any other table only the one I have trouble
wiht.
Sounds crazy and it is driving me nuts!!!!!!

I have tried everythig, strippped off the triggers on the table and

I would really initiate your help in advance.
Fardad
Nov 12 '05 #1
Share this Question
Share on Google+
3 Replies

P: n/a
I'll bet your table has at least one memo field.

Add a timestamp field to the table in SQL Server, and everything
will be fine. The problem is that, because of the memo field, the
client can't determine with certainty that the record hasn't been
changed by someone else. Just add the timestamp and see what
happens.
--

Danny J. Lesandrini
dl*********@hotmail.com
http://amazecreations.com/datafast
"Fardude" <fa*****@bes.ci.portland.or.us> wrote ...
I have a few tables in SQL Server 2000 and a small Access 97 that has
linked tables used to insert/update/delete into SQL Server 2k tables.

Everything works fine except Updating one of these table through
Access, I get
"Write conflict error" which basicaly says since you have updated
this record some other user has updated it. I know for sure this is
not True, becuase noone else has access t this database.
This does not happen to any other table only the one I have trouble
wiht.
Sounds crazy and it is driving me nuts!!!!!!

Nov 12 '05 #2

P: n/a
"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in message news:<bt************@ID-82595.news.uni-berlin.de>...
I'll bet your table has at least one memo field.

Add a timestamp field to the table in SQL Server, and everything
will be fine. The problem is that, because of the memo field, the
client can't determine with certainty that the record hasn't been
changed by someone else. Just add the timestamp and see what
happens.
--

Danny J. Lesandrini


In my experience this isn't caused by a Memo field, but by a date
field. When Access retrieves the date from SQL Server, it does some
rounding or truncating, and so when the time comes to update the
record, and the two records are compared, the date fields don't match,
and so Access thinks that someone has been and gone and changed the
record. Danny is right about the timestamp field - this should sort
the problem.

Edward
--
The reading group's reading group:
http://www.bookgroup.org.uk
Nov 12 '05 #3

P: n/a
On 6 Jan 2004 01:52:51 -0800, te********@hotmail.com (Edward) wrote:
"Danny J. Lesandrini" <dl*********@hotmail.com> wrote in message news:<bt************@ID-82595.news.uni-berlin.de>...
I'll bet your table has at least one memo field.

Add a timestamp field to the table in SQL Server, and everything
will be fine. The problem is that, because of the memo field, the
client can't determine with certainty that the record hasn't been
changed by someone else. Just add the timestamp and see what
happens.
--

Danny J. Lesandrini


In my experience this isn't caused by a Memo field, but by a date
field. When Access retrieves the date from SQL Server, it does some
rounding or truncating, and so when the time comes to update the
record, and the two records are compared, the date fields don't match,
and so Access thinks that someone has been and gone and changed the
record. Danny is right about the timestamp field - this should sort
the problem.

Edward


That's basically right. Memo fields are ignored by Access optimistic locking
leading to false negatives, and date and floating point number fields are
subject to rounding error leading to false positives. In my experience, date
fields actually aren't the most common cause, floating point numbers are.

If you add a TIMESTAMP column, that solves both types of problem. Since JET
knows it can use the TIMESTAMP as a simple and incontrovertible check to see
if data has been changed, it uses that and does not check the other field
values.
Nov 12 '05 #4

This discussion thread is closed

Replies have been disabled for this discussion.