Member Avatar for dnabukalu

hello
someone there could have met a similar problem. please help me out
Am using this commant to save data to an sql server database.
me.validate()
me.bindingsource.endedit()
me.tableadapter.update(me.dataset.datatable)

but when i click the save button on my winform it brings an error "System.Data.DBConcurrencyException: ConcurrencyViolation: The UpdateCommand affected 0 of the expected 1 records"

and in the database table all fields are recorded as <null>

i'll be grateful

  • 3 Contributors
  • 2 Replies
  • 100 Views
  • 5 Days Discussion Span
  • Latest Post Latest Post by manal

Dani AI

Generated

A DBConcurrencyException that says "UpdateCommand affected 0 of the expected 1 records" usually means the UPDATE (or DELETE) statement that the TableAdapter sent did not match any rows in the database. That can be caused by optimistic-concurrency checks (WHERE uses original column values), by missing/incorrect primary key metadata, by NULLs or datatype mismatches in the generated WHERE clause, or by the DataRow having the wrong RowState because AcceptChanges was called too early. This is not always two users editing the same row simultaneously — is correct that true multi-user concurrency is one possibility, but often the problem is a mismatch between the DataSet state and the SQL the adapter actually issues. The fact that records in the table appear as all NULL suggests parameter/source mapping or default/trigger behavior is also worth checking.

Try these targeted debugging steps:

  • Capture the exact UPDATE statement and parameter values your app sends (SQL Profiler or Extended Events). Run that statement manually in SSMS with the same parameter values to see why it returns 0 rows.
  • In the DataSet designer, confirm the DataTable has a primary key defined and that the TableAdapter’s WHERE clause is what you expect (many designers include every column by default).
  • Verify parameter SourceColumn and SourceVersion mappings so the adapter uses Original values where intended (and that NULLs are handled appropriately).
  • Inspect each DataRow.RowState before calling Update to ensure rows are Added/Modified and AcceptChanges wasn’t called earlier.
  • Check for triggers, computed columns or defaults that change stored values after the UPDATE (those will make original-value checks fail).

If optimistic concurrency is getting in the way, consider adding a rowversion column and basing concurrency on it:

ALTER TABLE YourTable ADD RowVersion rowversion;

Then refresh the TableAdapter so the rowversion is selected and used in the WHERE clause, or simplify the adapter to use only the primary key for the WHERE. As suggested, also double-check column datatypes and parameter mappings — they often point to the real cause.

Recommended Answers

All 2 Replies

Member Avatar for preetham.saroja

hai,
First check -whether all the fields are being specified& used in the query.And then check out whether datatype used for the fields are same as datatype used while in the update query.,,,

Member Avatar for manal

maybe two users try to change the same database at same time , read this link and this too

good luck :)

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.