Accept/Reject Cascading - DataSet

[Mr Newbie]

DataSet Parent/Child + Relation.

When you update the parent table, then after each row is updated in the db,
the adapter will call AcceptChanges on that row, marking that row as
unchanged. When AcceptRejectRule is set the Cascade, then AcceptChanges is
called on all related child rows marking them as unchanged too.

In what scanario would this cascade be useful ?

 

[luxspes]

DataSet Parent/Child + Relation.

When you update the parent table, then after each row is updated in the db,
the adapter will call AcceptChanges on that row, marking that row as
unchanged. When AcceptRejectRule is set the Cascade, then AcceptChanges is
called on all related child rows marking them as unchanged too.

In what scanario would this cascade be useful ?

Whenever you have a master detail relationship? :$

 

[Mr Newbie]

Not true.

I am using a master detail relationship, but I dont want the changes to a
master record to be reflected neccesarilly to its children when the specific
data changes does not warrant it.

Take a situation where we create a master first and then its children in the
dataset. Then you create the master in th SQL database but all your children
are then marked unchanged stopping you from addin them too.

 

[luxspes]

Not true.

I am using a master detail relationship, but I dont want the changes to a
master record to be reflected neccesarilly to its children when the specific
data changes does not warrant it.

Take a situation where we create a master first and then its children in the
dataset. Then you create the master in th SQL database but all your children
are then marked unchanged stopping you from addin them too.

If the temporary (in dataset) primary key of the master row changes on
saving (i.e. when using autoincrement in the database) then, if you dont
change the reference of the child row to match the new primary key of
the master... you will end up with orphaned records... wouldn't you?

 

[Mr Newbie]

Yes, but this particular rule cascase Accept/Reject Rule calls the Accept
Changes in the child, and this means that they will not be inserted by the
update method of the DataAdapter.

Try it !

 

[Bart Mermuys]

Hi Mr Newbie,

DataSet Parent/Child + Relation.

When you update the parent table, then after each row is updated in the
db,
the adapter will call AcceptChanges on that row, marking that row as
unchanged. When AcceptRejectRule is set the Cascade, then AcceptChanges
is
called on all related child rows marking them as unchanged too.

In what scanario would this cascade be useful ?

I found a thread on google describing one situation where it can be
required:

http://groups.google.be/group/micro...ctrule++cascade&rnum=2&hl=nl#5c11a31b0eeb225e

HTH,
Greetings

 

[Mr Newbie]

Hmm......, Tricky eh!

Well, it sounds like there is no hard and fast way to deal with this, it's a
case of grow your own solution depending on the type of implementation you
need.

Its a Delete vs Create dialema when you are dealing with both parent AND
child variations in the local Dataset.

Thanks for the link.

 

[Bart Mermuys]

Hi,

Hmm......, Tricky eh!

Well, it sounds like there is no hard and fast way to deal with this, it's
a case of grow your own solution depending on the type of implementation
you need.

Sort off, yes.

The link is mostly about the fact that some databases allow you to delete a
parent row in which case it deletes the child rows itself. And then it
depends on whether you take advantage of that or not. You don't have to you
can still first delete the child rows and then the parent row.

The update sequence for the latter is explained in "Managing an @@IDENTITY
Crisis" and requires AcceptRejectRule to be None.

Greetings

 

[Mr Newbie]

Thanks Bart. I did read Bill's note on the @@Identity crisis which was quite
helpfull

 

[David Sceppa [MSFT]]

Nice catch, Bart. It's always nice to see a two and a half year old
response to a thread is still helpful.

David Sceppa
Microsoft
This posting is provided "AS IS" with no warranties,
and confers no rights. You assume all risk for your use.
© 2005 Microsoft Corporation. All rights reserved.