By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
443,889 Members | 1,373 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 443,889 IT Pros & Developers. It's quick & easy.

Concurrency Violation on Delete command; first record only

P: n/a

Have a problem that consistantly occurs in my applications where using
a DataAdapter (OLEDB) and a dataset.

Using a simple process of adding a row to the dataset table and then
calling the dataAdapter.Update method. The row adds.
However if I delete that new row immediately via the dataset, I get a
concurrency violation. By deleting via dataset, I mean,
dataset.table(rownum).Delete() then once again calling the
dataAdapter.Update method.

Of relevance: if using a command instead, and writing the SQL for the
delete, I do not experience the problem. Also, if altering the order of
events, such as adding a second row before deleting the first, it works
fine. If I add the first row, then stop the application, then start the
application, and then delete the first row, it works fine. Also this
happens in apps written in C# and VB

I am thinking it might have something to do with the primary key. In
all cases, the PK has been an AutoNumber (like SQLs identity).

I would be extremely thankful for any help you can give on this. Its
bothered me for some time and usually I can take the time to workaround
with a command object instead. But I'd prefer to understand why this is
not working.

Many thanks,
Steven Nagy

Nov 16 '05 #1
Share this Question
Share on Google+
4 Replies

P: n/a
Hi again,
Still have not resolved this, would appreciate any help.


Nov 16 '05 #2

P: n/a
A wild guess is that if you add and delete a row and then call update,
update checks on delete to see if the row existed intact on the initial
before the update and since the row did not exist before the update it
a concurrency violation. Concurrency ALL logic insist that the record
intact as it did on the initial read. Concurrency PRIMARY logic insist
that the
primary key existed on the initial read. Concurrency DIRTY logic inist
that the
primary key and any updated fields existed intact on the initial read.


*** Sent via Developersdex ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #3

P: n/a
Hi Jeff, and thanks for your response.

Unfortunately I am performing operations in this order:
Add a row to dataset.datatable
call dataAdapter.Update(dataset.datatable)
Delete same row from dataset.datatable
call dataAdapter.Update(dataset.datatable)

Is there a way to weaken the concurrency checking to let this operation
occur anyway?
The application is a standalone app and nothing outside of it will be
accessing the database.

Many thanks,

Nov 16 '05 #4

P: n/a
Off the top of my pointed head I would think that reloading the dataset
each update would solve the problem. If this is a standalone app with no
simultaneous users to the database, I believe you can tell the
wizard not to use optimistic concurrency.


*** Sent via Developersdex ***
Don't just participate in USENET...get rewarded for it!
Nov 16 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.