Re: Merging DataSet (Added and Unchanged)

I do the same thing...
It does feel like a kludge...

One alternative is to use GUID's as primary keys and make use of the NewGuid
functions in .Net, so the primary key generation occurs in the client app
rather than the database engine.

You gotta remember that you are essentially synchronizing 2 databases (one
at the database server, and one at the client app in the form of the
dataset).  Only one of these databases is capable of creating valid primary
keys (the database server, e.g MSSQL), but the client app still needs some
sort of temporary primary key to maintain the relationships in the dataset.


Since there's no easy way to determine that a 'client app' row with a temp
key is the same as a 'db server side' row with a real PK without comparing
every single field in the row, but then you'd have to determine if just
comparing two rows on a data field by data field basis (not including
primary key fields) is a valid way to match up rows between the two systems,
you'd have to take into consideration rows that appear to match but are
actually only the same based on data fields (not including key fields).

But then again, that's what key fields are for, telling the difference
between two rows that are identical in all fields other than the PK.
Think 2 people with same name and same birthday, the only difference between
(only considering name & DoB) the people would be their SSN (or other valid
national ID number....or DNA sample.....etc)


Phil

-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps and
controls [mailto:DOTNET-WINFORMS@xxxxxxxxxxxxxxxxxxx] On Behalf Of Greg
Robinson
Sent: Wednesday, February 25, 2004 9:57 AM
To: DOTNET-WINFORMS@xxxxxxxxxxxxxxxxxxx
Subject: [DOTNET-WINFORMS] Merging DataSet (Added and Unchanged)

The docs state

"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. Source rows with a DataRowState value
of Added are matched to new target rows with the same primary key values as
the new source rows."

This part:

"Source rows with a DataRowState value of Added are matched to new target
rows with the same primary key values as the new source rows."

h

as always confused me.  Our app sends an Added DataRow to our DAL (we call
the client Dataset's GetChanges method and send this smaller DataSet across
the wire).

Our DAL does the insert.  A primary key is returned as part of the insert.
The DataRow now has the PrimaryKey value and is now marked as Unchanged.
The client 'Added' DataRow does not have the PrimaryKey though.  It is
storing a dummy PrimaryKey.

So, we return to the client with an Unchanged DataRow that is storing the
correct PrimaryKey from sql server.

So, how can this 'match' work?  The Source DataRow is marked as Added.
However, the returning DataRow's PrimaryKey will never match.

What we do now, is just prior to calling Merge, we remove all Added DataRows
from the client DataSet.  The we call Merge.

This works, but seems like extra overhead to me.

Greg Robinson
Custom Data Systems, Inc.
www.cds-am.net