D
Derrick
Hello;
I've got a problem where DataSet.Merge is causing duplicate records,
and then throwing a constraint failure exception because of duplicate
primary keys.
I've seen a similary problem discussed here where the key fields were
set to Auto-increment integers. I am not using this - I'm using GUIDs
as primary keys.
My scenario: I'm doing a (supposedly) simple remoting app. Note -
there is no database server, I'm only using the dataset as a
collection, not to do any SQL. Instances of the same typed dataset
exist on both sides of the remoting channel (I'll call one "local",
the other "remote"). On the remote side, when a row in any table is
changed, I call the DataSet.GetChanges() method to extract those
changes. I then send this "sub-dataset" from the remote side to the
local side, where it is to be merged with it's copy, thus updating
it. This is where I get the exception.
I can look at the data before the merge, and everything seems to line
up. If I only modify one row, I can look at both copies and see that
row's state listed as "Unchanged" (with the old data) in the local
copy, and "Modified" (with the new data) in what was received from the
remote side. I can compare the bytes of the GUID primary key and see
they are equal. I can see the field whose data has changed. From the
description given on MSDN, I seem to have all the criteria for a
successful merge (http://msdn2.microsoft.com/en-us/library/
4swwh51k.aspx). However, when I look at the local data after the
merge blows up on the constraint exception, I can see the duplicate
field in my table, with both the old & new data.
This has me stumped. I could write my own merge function, but why?
If anyone can shed light on this, I'd appreciate it!
Derrick
I've got a problem where DataSet.Merge is causing duplicate records,
and then throwing a constraint failure exception because of duplicate
primary keys.
I've seen a similary problem discussed here where the key fields were
set to Auto-increment integers. I am not using this - I'm using GUIDs
as primary keys.
My scenario: I'm doing a (supposedly) simple remoting app. Note -
there is no database server, I'm only using the dataset as a
collection, not to do any SQL. Instances of the same typed dataset
exist on both sides of the remoting channel (I'll call one "local",
the other "remote"). On the remote side, when a row in any table is
changed, I call the DataSet.GetChanges() method to extract those
changes. I then send this "sub-dataset" from the remote side to the
local side, where it is to be merged with it's copy, thus updating
it. This is where I get the exception.
I can look at the data before the merge, and everything seems to line
up. If I only modify one row, I can look at both copies and see that
row's state listed as "Unchanged" (with the old data) in the local
copy, and "Modified" (with the new data) in what was received from the
remote side. I can compare the bytes of the GUID primary key and see
they are equal. I can see the field whose data has changed. From the
description given on MSDN, I seem to have all the criteria for a
successful merge (http://msdn2.microsoft.com/en-us/library/
4swwh51k.aspx). However, when I look at the local data after the
merge blows up on the constraint exception, I can see the duplicate
field in my table, with both the old & new data.
This has me stumped. I could write my own merge function, but why?
If anyone can shed light on this, I'd appreciate it!
Derrick