Concurrency Violation

  • Thread starter Thread starter Dustin Davis
  • Start date Start date
D

Dustin Davis

When the following subroutine executes I get a concurrency violation.
I'm not sure why. Can someone help provide a clue for me?

(drvZones is a DataRowView)
 
According to one book that I have, when using a SqlDataAdapter, it
throws a DBConcurrencyException if the UpdateQuery doesn't modify any
rows. So maybe your tableAdapter.Update isn't working, and is giving you
the exception to tell you that.

That would happen when someone else has updated the row after you
displayed it and before you updated yours, or if somehow your data row
is marked as an Update, and it can't find the record to be updated.

That's my best guess. I think this is related to your other problem.

Robin S.
----------------------------------------
 
That may have been it - I was updating records that were not necessarily
changing. I did some more digging on the Internet and found out how to
turn off optimistic concurrency and that seemed to solve the problem.

Thanks.
 
That means that your code will not be able to discern whether the
update was successful or not. Just FYI.

Robin S.
------------------------
 
Which brings up the question - how are you getting concurrency problems
in that case?
Robin S.
-------------------
 
Dustin,

The thing from that creates the most unwanted concurrency errors is the
autoidentifier.

In my opinion is that not made for datatables and things like that, but more
for the less advanced use in the past.

If you don't clean your datasets after an update with an autoident, you will
have more rows than there really exist. Can this be the problem?

Cor
 
Assuming it's the same routine he asked about in an earlier post,
he has bigger problems than that. He was kind of changing
the dataset in one place, and the bindingsource in another,
and it was kind of mixed up. I spent a considerable amount of
time looking at it and marked it up and send it back to him;
hopefully that will fix this problem as well.

Robin S.
 
That's what I can't figure out and why I'm posting here... :(

Oddly, I thought this fixed the problem, but I got another concurrency
problem while testing, even with optimistic concurrency turned off :baffled:
 
That's hardly fair! Give yourself a break. Just because you don't
know exactly how to do something doesn't mean you can't do it.
I've spent hundreds of hours (literally) reading thousands of
pages (literally) of .Net books to try to figure this stuff out
(thank goodness, it seems to be working. ;-) and there's *still*
gobs of stuff I haven't dealt with (multi-threading and reflection,
to name two).

Robin S.
 
I'm hoping this is referencing the form we discussed in e-mail, and
that the stuff I sent you fixed your problem(s).

Robin S.
-------------------------------
 
That's funny. Multi-threading is my next issue to tackle. I'm trying to
find a solution for this error: "..cannot be instantiated because the
current thread is not in a single-threaded apartment"
 
It *is* funny, because after saying that, I decided to put
a progress bar up when I'm running stuff, and found out the
best way to do that is with threading. I mostly got it to
work. I think using the BackgroundWorker is simpler than
the other threading stuff, though.

My underlying program does OLE Automation of Excel. Sometimes
after it creates the report and I close Excel, Excel is still
in the processes list. It's never there if I run it w/o the
threading. And my class implements IDisposable. So I don't know
what I'm going to do about that. Sigh.

Good luck figuring out yours. Have you checked out the Francesco
Balena book, "VB2005: The Language"? I has some quite usable
examples and information.

Did the other stuff I sent you help with your updating? Does
it work?

Robin S.
-----------------------------------------------------------
 
Back
Top