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