Larry Smith

Hi there,

I'm dealing with an almost identical problem posted here last year: http://forums.microsoft.com/MSDN/ShowPost.aspx PostID=632312&SiteID=1

Can someone confirm if the following is a bug. Thanks.

///////////////////////////////////////////////////
DataSet ds1 = new DataSet();
DataTable dt1 = new DataTable();
dt1.Columns.Add("ID", typeof(int));

DataRow dr1 = dt1.NewRow();
dr1[0] = 1;
dt1.Rows.Add(dr1);

DataRow dr2 = dt1.NewRow();
dr2[0] = 2;
dt1.Rows.Add(dr2);

ds1.Tables.Add(dt1);
ds1.AcceptChanges();

DataSet ds2 = ds1.Copy();
ds2.Tables[0].Rows[0].Delete(); // Delete ID 1

DataSet ds3 = ds2.GetChanges();
ds1.Merge(ds3);
///////////////////////////////////////////////////

After the merge, "ds1" contains the original (unaltered) rows plus one extra
(deleted) row with ID 1. Why isn't the original row with ID 1 being
deleted instead




Re: .NET Framework Data Access and Storage Is this a bug?

Bill Lin - MSFT

This is by design. From MSDN online, "When merging a new source DataSet into the target, any source rows with a DataRowState value of Unchanged, Modified, or Deleted are matched to target rows with the same primary key values."

So if you want to acheive the behavior you desired, please add this line to your code

dt1.PrimaryKey = new DataColumn[] { dt1.Columns["ID"] };






Re: .NET Framework Data Access and Storage Is this a bug?

Larry Smith 999999

Thanks for the feedback. It turns out that the designer had a hiccup and "deleted" the primary key in one of my (real) tables. After fixing it the problem resolved itself as expected. The designer isn't always 100% stable and I've experienced strange problems like this before. The example I posted was from another source however (I neglected to provde the primary key) but unfortunately it took me hours to realize what happened in my real tables (where the keys haven't been touched in ages). Anyway, thanks again for your help (appreciated).