TableAdapter Update Error with DBConcurrency (in VB.NET)

This may be a basic newbie question.  If I use a tableadapter to fille a datatable, make some changes a datarow and call an UPDATE, make some more changes to the same datarow, then call UPDATE again without reloading the data (through the FILL command), I get a DBConcurrency error.  Is this by design?  Do I need to fill the table again before I call UPDATE a second time?  Here is some example code.  (backend is SQL Server 2008).  Is there an easy way to allow for this so I can minimize roundtrips to the database?


        Using ta As New TestDataSetTableAdapters.ResourceTableAdapter
            ta.FillByResourceID(Me.TestDataSet.Resource, ID)
        End Using
        Dim dr As TestDataSet.ResourceRow
        dr = TestDataSet.Resource(0)
        Using ta As New TestDataSetTableAdapters.ResourceTableAdapter
            dr.Comments = "First"
            ta.Update(Me.TestDataSet.Resource)

            dr.Comments = "Second"
            'This next UPDATE will give the DBConcurrencyException:  Concurrency violation: the UpdateCommand affected 0 of the expected 1 records.
            ta.Update(Me.TestDataSet.Resource)
        End Using

Open in new window

eeyoAsked:
Who is Participating?

Improve company productivity with a Business Account.Sign Up

x
 
Vadim RappConnect With a Mentor Commented:
You need to re-fill the dataset only if the table on the server has really changed between your updates, such as by another session (another user, or even yourself), or maybe by the trigger. For example, if the table has trigger that puts last-updated timestamp in a column, then your client won't know about that.

This can be addressed by adjusting UPDATE statement of the adapter. The one generated by visual studio will verify all the columns of the row being updated, if they are still the same as when you read the row from the server. If any of them is not the same, that's when you receive the message about concurrency. You can remove those verifications if you are sure it's OK to do.

For example, if the table has column1 primary key, column2 and column3, the standard update statement will be:

update table set column2=@newvalue2 where column1=@primary_key and column2=@oldvalue2 and column3=@oldvalue3

if you are sure that there's in fact no concurrency, and even if column2 or 3 has somehow changed from when you read it, it's ok to override, change to

update table set column2=@newvalue2 where column1=@primarykey
0
 
Vadim RappCommented:
We tried to reproduce your problem, but it did not happen, and 2nd update worked as expected. See this sample:

https://filedb.experts-exchange.com/incoming/ee-stuff/8347-ee.rar


You will have to adjust connection string. The table we used was created by the following:

create table resource(id int not null primary key,resource varchar(50), comments varchar(50))
insert into resource select 1 ,'none','none'
0
 
eeyoAuthor Commented:
I am using a timestamp field as well.  Maybe that's the difference.

It looks like others are having the same issue.  One solution is to just re-fill the datatable again, which can be resource heavy.
Link Here
0
 
eeyoAuthor Commented:
Unfortunately, I have not been able to resolve the issue with the above suggestions.  I think I will just forgo efficiency and just refill the datatables again.
0
 
eeyoAuthor Commented:
Not the direct solution, but there may be some unusual situation with my setup.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.