Re: Merging DataSet (Added and Unchanged)

My main concern is why do the docs recommend this approach when Adding
DataRows and it simply does not work.  There is no way to get this to work
without manually doing something.  The PKs will never match up so why even
suggest doing this in the docs?



-----Original Message-----
From: Discussion forum for developers using Windows Forms to build apps
and controls [mailto:DOTNET-WINFORMS@xxxxxxxxxxxxxxxxxxx]On Behalf Of
Bill Schmidt
Sent: Thursday, February 26, 2004 8:41 AM
To: DOTNET-WINFORMS@xxxxxxxxxxxxxxxxxxx
Subject: Re: [DOTNET-WINFORMS] Merging DataSet (Added and Unchanged)


Jeff,

Actually, my bug fix was more comprehensive than I described:  I turned off
EnforceConstraints, copied the rows for every table in our typed DataSet
(which has relationships), then turned on EnforceConstraints (which would
generate an error if any relationships are violated).  I then tested it for
a case where only a single record was returned.

Thanks to your posting, I now realize that my 'fix' won't work in the case
where related records (in different tables) are returned.  I guess its back
to the drawing board.  I appreciate learning about a bug in our system
before the testers discover it ;)  I'll post again if I come up with
anything worth mentioning.

Bill

On Thu, 26 Feb 2004 06:40:32 -0500, Block, Jeffrey A. (Jeff)
<jeff.block@xxxxxxxxxx> wrote:

>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
>**********************************************************************