Re: Merging DataSet (Added and Unchanged)

I've been watching this thread with great interest...I too feel that the
synchronizing of the DB and client is cumbersome for added rows.  The GUID
approach is viable and eliminates most of the challenges that we are seeing,
I believe.  Personally, I just like the "feel" of that sequential numbering
of the identity/autoincrement column.

Just last night, as I was reviewing some other system challenges due to the
latest virus, I caught the fact that one of our PCs had a bad date setting
(due to some _other_ 3rd party software, grrrrrr), that was putting
2/4/2023, instead of 2/23/2004, but was able to quickly discount them as
having nothing to do to the current issues since the ID column was out of
"sequence" with the current rows being added.  I don't think this would have
not been possible with GUIDs.

So, I would really like to stay away from the GUID, if possible, but more
from a comfort standpoint than anything technical.  That said, there is a
lot more overhead in the tables from a GUID perspective than an int[32]
column since they would just be stored as a char(32) (haven't really looked
at the length, could be off, but I think the point comes across...) in the
main and referencing tables.

With the current means of removing the added rows, I would assume that you
are not able to create any child rows of that added row, correct?  One of
the big selling points is that you would be able to add say an order and all
its items into the Orders and OrderItems DataTables and then just perform
the update and the keys get cascaded (I believe there is a property that
controls this, but is escapes me currently, but it can be done from the
reading I've done.) properly.  Unless you don't have the relationship
created or have EnforceConstrants = false (which sort of defeats the purpose
of the DataSet), it seems that you would not be able to perform this type of
operation without first "inserting" the order row into the DB and getting
the real ID returned and updated as has been discussed.  <shrug>

It is just this remoted case that has me, and I think most others, stumped.
Are we missing something or are the workarounds and kludgy feelings
necessary.  Is there anything being worked on for Whidbey to address this
(i.e. ObjectSpaces?!?).

Jeff Block


-----Original Message-----
From: Bill Schmidt [mailto:billschmidt2@xxxxxxx]
Sent: Thursday, February 26, 2004 12:28 AM
To: DOTNET-WINFORMS@xxxxxxxxxxxxxxxxxxx
Subject: Re: [DOTNET-WINFORMS] Merging DataSet (Added and Unchanged)

Greg,

I just fixed a bug today having to do with this subject.  We have a remoted
method that passes back a DataSet with a DataTable containing a single
(new) row.  Since this is a typed DataSet with AutoIncrement turned on for
the primary key columns, the PK for the returned row is always -1.

Prior to the bug fix, we were merging the returned DataSet into our master
DataSet on the client.  This works fine the first time, but the second and
subsequent times it overwrites the row merged in on the previous execution.
The fix was to write a routine that adds a new (empty) row and copies all of
the non-PK fields from the returned row, instead of doing the Merge.

Bill

On Wed, 25 Feb 2004 09:57:15 -0500, Greg Robinson <greg@xxxxxxxxxx> wrote:

>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


**********************************************************************
PLEASE NOTE: The above email address has recently changed from a previous 
naming standard -- if this does not match your records, please update them to 
use this new name in future email addressed to this individual.

This message and any attachments are intended for the
individual or entity named above. If you are not the intended
recipient, please do not forward, copy, print, use or disclose this
communication to others; also please notify the sender by
replying to this message, and then delete it from your system.

The Timken Company
**********************************************************************