Hi,
Pretty much as the subject says,
I have an ADP linked to a SQL Server 2000 database. On one table I have a
FOR UPDATE trigger used for auditing purposes.
When attempting to update that trigger in the ADP - be that via a view or
directly in the table I get a write conflict error that Access pops up when
the row is being updated by another user:
"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 has
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"
With "Save Record", "Copy to Clipboard" and "Drop Table" command buttons.
Can anyone please shed any light as to why this is happening and how I can
prevent it?
Thanks
Chris.
sds - 08 Jul 2005 15:07 GMT
xfczxc
-----Original Message-----
From: Chris Strug [mailto:hotmail@solace1884.com]
Posted At: Friday, July 08, 2005 7:30 PM
Posted To: microsoft.public.access.adp.sqlserver
Conversation: Write conflict in ADP on updating table including triggers
Subject: re: Write conflict in ADP on updating table including triggers
Hi,
Pretty much as the subject says,
I have an ADP linked to a SQL Server 2000 database. On one table I have a
FOR UPDATE trigger used for auditing purposes.
When attempting to update that trigger in the ADP - be that via a view or
directly in the table I get a write conflict error that Access pops up when
the row is being updated by another user:
"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 has
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"
With "Save Record", "Copy to Clipboard" and "Drop Table" command buttons.
Can anyone please shed any light as to why this is happening and how I can
prevent it?
Thanks
Chris.
sds - 08 Jul 2005 15:08 GMT
-----Original Message-----
From: Chris Strug [mailto:hotmail@solace1884.com]
Posted At: Friday, July 08, 2005 7:30 PM
Posted To: microsoft.public.access.adp.sqlserver
Conversation: Write conflict in ADP on updating table including triggers
Subject: re: Write conflict in ADP on updating table including triggers
Hi,
Pretty much as the subject says,
I have an ADP linked to a SQL Server 2000 database. On one table I have a
FOR UPDATE trigger used for auditing purposes.
When attempting to update that trigger in the ADP - be that via a view or
directly in the table I get a write conflict error that Access pops up when
the row is being updated by another user:
"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 has
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"
With "Save Record", "Copy to Clipboard" and "Drop Table" command buttons.
Can anyone please shed any light as to why this is happening and how I can
prevent it?
Thanks
Chris.
Steve Jorgensen - 08 Jul 2005 16:06 GMT
I'm not sure what's causing the precise problem you are having, but there's
another really common problem with triggers and ADO, so I'll describe that,
and see if it sheds any light on your problem...
ADO uses the SQL Server @@IDENTITY variable to determine the key of the record
you insert via an ADO recordset (even though SQL Server now supplies a more
reliable mechanism). @@IDENTITY returns the IDENTITY value that was generated
for the last insert statement in the connection, but if a trigger fires and
inserts a record into another table with an IDENTITY column, the value for the
record in -that- table is obtained, not the value for the record that was
explicitly being added. Of course, DAO also has this problem.
The most obvious work-around for this is to make sure that any trigger that
fires on INSERT does not insert rows into another table that has an IDENTITY
column.
>Hi,
>
[quoted text clipped - 23 lines]
>
>Chris.
Malcolm Cook - 08 Jul 2005 17:24 GMT
re:
> The most obvious work-around for this is to make sure that any trigger that
> fires on INSERT does not insert rows into another table that has an IDENTITY
> column.
but if you find you simply must, then see
http://groups-beta.google.com/group/microsoft.public.access.adp.sqlserver/msg/2f
5ce86f0fe13b0a

Signature
Malcolm Cook - mec@stowers-institute.org
Database Applications Manager - Bioinformatics
Stowers Institute for Medical Research - Kansas City, MO USA
Steve Jorgensen - 09 Jul 2005 05:14 GMT
That's great - I wish I'd known that trick for about the past 9 years.
>re:
>> The most obvious work-around for this is to make sure that any trigger
[quoted text clipped - 5 lines]
>but if you find you simply must, then see
>http://groups-beta.google.com/group/microsoft.public.access.adp.sqlserver/msg/2f
5ce86f0fe13b0a
Malcolm Cook - 10 Jul 2005 04:17 GMT
yeah - i've got the following trigger template calling the following sp:
hope it hleps - malcolm...
CREATE TRIGGER [TRIGGERNAME] ON [dbo].[tablename] FOR INSERT, UPDATE,
DELETE AS
/**
PURPOSE:
AUTHOR: Malcolm Cook (mec@stowers-institute.org)
**/
set nocount on --for benefit of MS Access 2002
declare @ID as bigint
SET @ID = @@IDENTITY
IF UPDATE(somecolumn)
BEGIN
exec sp_reset_IDENTITY @ID --for benefit of MS Access 2002
END
CREATE PROCEDURE [dbo].[sp_reset_IDENTITY]
(@ID as bigint)
/**
Pupose: reset global @@IDENTITY
Usage: As the last thing done in a trigger, if you think that some client
application is expecting @@IDENTITY to reflect the last inserted row on for
the triggers base table. Trap @@IDENTITY at the head of your
trigger, like this
set nocount on --don't forget this or access gets bulloxed up
declare @ID as bigint
SET @ID = @@IDENTITY
and pass it to this sp_ at the end of the trigger, like this:
exec sp_reset_IDENTITY @ID
Author: Malcolm Cook (mec@stowers-institute.org)
Kudos: to Nik Sestrin (sestrin@astfnet.kuzbass.net) who described the
workaround in
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=O1BcqJTQBHA.1788%40tkmsf
tngp05
**/
AS
DECLARE @strSQL varchar(300)
SET @strSQL=N'SELECT Identity (Int, ' + Cast(@ID As Varchar(10)) + ',
1) AS ignore INTO #sp_reset_IDENTITY_tmp'
EXECUTE (@strSQL)
GO
> That's great - I wish I'd known that trick for about the past 9 years.
>
[quoted text clipped - 8 lines]
>
>http://groups-beta.google.com/group/microsoft.public.access.adp.sqlserver/msg/2f
5ce86f0fe13b0a
aaron.kempf@gmail.com - 11 Jul 2005 18:31 GMT
i just dont understand the problem.
if it's a bug with a simple trigger; can't Microsoft FIX IT?
I'm tired of work-arounds; I want MICROSOFT TO START FIXING BUGS IN ADP.
aaron.kempf@gmail.com - 11 Jul 2005 18:32 GMT
i just dont understand the problem.
if it's a bug with a simple trigger; can't Microsoft FIX IT?
I'm tired of work-arounds; I want MICROSOFT TO START FIXING BUGS IN ADP.
Steve Jorgensen - 12 Jul 2005 15:47 GMT
>i just dont understand the problem.
>
>if it's a bug with a simple trigger; can't Microsoft FIX IT?
>
>I'm tired of work-arounds; I want MICROSOFT TO START FIXING BUGS IN ADP.
It looks to me like Microsoft has given up on ADPs.
Chris Strug - 15 Jul 2005 10:48 GMT
Wow, didn't expect to get so much of a reaction!
I found that including the SET NOCOUNT ON statement in each trigger actually
resolved the issue but that link you provided should prove to be very useful
in the future!
Thanks
Chris.
giorgio rancati - 12 Jul 2005 14:37 GMT
> Hi,
>
[quoted text clipped - 6 lines]
> directly in the table I get a write conflict error that Access pops up when
> the row is being updated by another user:
Hy Chris,
add a timestamp field in your table, this will solve the resync problem.
sorry for my english :)
Ciao Giorgio
giorgio rancati - 12 Jul 2005 14:41 GMT