[sigh] I'm not saying that you are doing anything special. I am saying
that:
1) A concurrency error happens when @@ROWCOUNT = 0 after the UPDATE.
2) Therefore, we can deduce that for some reason @@ROWCOUNT = 0 after your
2nd update.
3) Therefore, something in the WHERE no longer matches any available
records.
4) You have to find out what that is. You have to do this whether or not it
makes any sense to you, whether or not it happens only on the 2nd update,
and whether or not you want to. ;-)
I would start by setting a breakpoint after the error and then go into Query
Analyzer and call up the record that was just updated, both before and after
the rollback. Then I would step through until you can see what parameter
values are being passed to the DB when you attempt the 2nd update. You
might also get yet a third copy of the record you're concerned with, just
before that 2nd update. You might also try to manually do a SELECT with the
same WHERE condition as the UPDATE to see if it returns anything.
Somewhere in there you will have an "AHAH! moment".
--Bob
"perspolis" <re*****@hotmai l.com> wrote in message
news:%2******** ********@TK2MSF TNGP09.phx.gbl. ..
in my project I have 2 tables (one master and another details)
first I update master then details..when I make a mistake in details and
update both ,the details gives me an error then I correct that error and
update both again..this time I get a concurrency error...I don't do
anything
special to get this error..
"Bob Grommes" <bo*@bobgrommes .com> wrote in message
news:#K******** ******@TK2MSFTN GP09.phx.gbl... Doesn't change the solution -- you have to determine why the second
UPDATE
isn't matching any records. Something makes the WHERE condition false
the
second time. What is it?
--Bob
"perspolis" <re*****@hotmai l.com> wrote in message
news:ul******** ******@TK2MSFTN GP09.phx.gbl... > thx all..I use a transaction..wh en an error occurs I rollback
> transaction..an d when I change my dataset again and correct that error the > concurrency error occures...
>
> "Bob Grommes" <bo*@bobgrommes .com> wrote in message
> news:#O******** ******@tk2msftn gp13.phx.gbl...
>> More generically, the original posted has a WHERE clause in the UPDATE
>> statement that is not matching any rows. It is possible, if he
>> crafted
> this
>> UPDATE himself, that he is doing something other than looking at a
> TimeStamp
>> or DateTime field, or a laborious comparison of all fields before and
>> after -- or that he has implemented them wrong.
>>
>> Figure out why the UPDATE isn't affecting any rows and you have the
> answer.
>> It doesn't matter that the datarow in the datatable has changed; it only >> matters whether SQL Server can find any matching record(s) to put the
>> changed data into.
>>
>> --Bob
