Write Conflict.. Urgent .. Please help.

[Pearl]

Hi,

I have the following issue when an user tries to enter a
new record into the Sql Server database through ADP:

WHen the user enters and new record and tries to transfer
control to another screen, they get a "Write Conflict"
dialog box asking them to Save Changes, Drop Changes or
Copy to Clip Board.

I am really zapped on this issue. Saw this issue
documented in the microsoft support website asking users
with Office 2002 to get an update... But my problem is
that this issue occurs in Office 2003 also for me.

No idea how to fix it... Could anybody please help me.

 

[Monte]

I have seen this error when the SQL table contains "bit"
type fields that do not have a default value (zero) set in
the table design. When you add or edit a record, SQL
Server (or MSDE) leaves these types of fields "null" (if
no data is entered into that field), and the null value
confuses Access into thinking two users have changed the
same record. I fixed the problem by making sure all "bit"
fields have a default value of zero, and none of the
existing records in the table have "null" in those fields.

 

[Pearl]

Thanks Monte.

In my case though, I have no Bit fields.. ALl my field
are either integer, datetime or ntext.

Any further help is appreciated.

 

[Sylvain Lafontaine]

A lot of things can go bad with ADP. By doing a profiling on the
SQL-Server, it is quite possible that you will see what ADP is trying to do
and how to correct it.

You can also try to write your own Resync command or to write a wrong Resync
command with the wrong number of arguments: ADP will see that it cannot use
this bad resync command and then will revert to the default resync operation
of ADODB; which is simply to return the same arguments without trying to
make a call to the SQL-Server. (By the way, this will also make your
updates run faster.)

Also, Access 2000 had often having a bad time with timestamp fields; so
removing them or upgrading to Access 2003 if necessary might be a good idea.

Finally, I suppose that all of your primary keys and foreign keys are well
defined for all of your tables and that you have set the Unique table
property of your form to the correct value; as this may help on some
occasions.

S. L.

 

[Pearl]

Thanks a lot Sylvain

-----Original Message-----
A lot of things can go bad with ADP. By doing a profiling on the
SQL-Server, it is quite possible that you will see what ADP is trying to do
and how to correct it.

You can also try to write your own Resync command or to write a wrong Resync
command with the wrong number of arguments: ADP will see that it cannot use
this bad resync command and then will revert to the default resync operation
of ADODB; which is simply to return the same arguments without trying to
make a call to the SQL-Server. (By the way, this will also make your
updates run faster.)

Also, Access 2000 had often having a bad time with timestamp fields; so
removing them or upgrading to Access 2003 if necessary might be a good idea.

Finally, I suppose that all of your primary keys and foreign keys are well
defined for all of your tables and that you have set the Unique table
property of your form to the correct value; as this may help on some
occasions.

S. L.




.

 

[Malcolm Cook]

did you fix this?

if not - do you have a trigger on the underlying table? if so, make sure
the trigger calls 'set nocount on ' first thing.

g'luck

 

[Pearl]

Hi,

Thanks Malcolm. The issue in my application was because
the subforms I was using was changing a field in the main
form After Update.

So, once I removed that macro from the "AFter Update"
event and put that macro in the "On exit" event of the
subform, everything worked fine.

Regards