|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Accept/Reject Cascading - DataSetDataSet 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 ? Mr Newbie wrote:
> DataSet Parent/Child + Relation. Whenever you have a master detail relationship? :$> > 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 ? > > 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. -- Show quoteBest Regards The Inimitable Mr Newbie º¿º "luxspes" <m*@privacy.net> wrote in message news:uu9ZuTb7FHA.4012@TK2MSFTNGP14.phx.gbl... > Mr Newbie wrote: >> 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 wrote:
> Not true. If the temporary (in dataset) primary key of the master row changes on > > 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. 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? Show quote > > > 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 ! -- Show quoteBest Regards The Inimitable Mr Newbie º¿º "luxspes" <m*@privacy.net> wrote in message news:eVQAWud7FHA.2716@TK2MSFTNGP11.phx.gbl... > Mr Newbie wrote: >> 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? > > >> >> Hi Mr Newbie,
"Mr Newbie" <h***@now.com> wrote in message I found a thread on google describing one situation where it can be news:OYz754R7FHA.1184@TK2MSFTNGP12.phx.gbl... > 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 ? required: http://groups.google.be/group/microsoft.public.dotnet.framework.adonet/browse_frm/thread/9fcf916b1247a77b/5c11a31b0eeb225e?lnk=st&q=%2Bacceptrejectrule+%2Bcascade&rnum=2&hl=nl#5c11a31b0eeb225e HTH, Greetings Show quote > > 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. -- Show quoteBest Regards The Inimitable Mr Newbie º¿º "Bart Mermuys" <bmermuys.nospam@hotmail.com> wrote in message news:uTQ62ie7FHA.1184@TK2MSFTNGP12.phx.gbl... > Hi Mr Newbie, > > "Mr Newbie" <h***@now.com> wrote in message > news:OYz754R7FHA.1184@TK2MSFTNGP12.phx.gbl... >> 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/microsoft.public.dotnet.framework.adonet/browse_frm/thread/9fcf916b1247a77b/5c11a31b0eeb225e?lnk=st&q=%2Bacceptrejectrule+%2Bcascade&rnum=2&hl=nl#5c11a31b0eeb225e > > HTH, > Greetings > >> >> > > Hi,
"Mr Newbie" <h***@now.com> wrote in message Sort off, yes.news:Oqw4qCf7FHA.2012@TK2MSFTNGP14.phx.gbl... > 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. 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 Show quote > > Its a Delete vs Create dialema when you are dealing with both parent AND > child variations in the local Dataset. > > Thanks for the link. > > -- > Best Regards > > The Inimitable Mr Newbie º¿º > > > "Bart Mermuys" <bmermuys.nospam@hotmail.com> wrote in message > news:uTQ62ie7FHA.1184@TK2MSFTNGP12.phx.gbl... >> Hi Mr Newbie, >> >> "Mr Newbie" <h***@now.com> wrote in message >> news:OYz754R7FHA.1184@TK2MSFTNGP12.phx.gbl... >>> 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/microsoft.public.dotnet.framework.adonet/browse_frm/thread/9fcf916b1247a77b/5c11a31b0eeb225e?lnk=st&q=%2Bacceptrejectrule+%2Bcascade&rnum=2&hl=nl#5c11a31b0eeb225e >> >> HTH, >> Greetings >> >>> >>> >> >> > > Thanks Bart. I did read Bill's note on the @@Identity crisis which was quite
helpfull -- Show quoteBest Regards The Inimitable Mr Newbie º¿º "Bart Mermuys" <bmermuys.nospam@hotmail.com> wrote in message news:OBVd$Ug7FHA.2384@TK2MSFTNGP12.phx.gbl... > Hi, > > "Mr Newbie" <h***@now.com> wrote in message > news:Oqw4qCf7FHA.2012@TK2MSFTNGP14.phx.gbl... >> 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 > > > >> >> Its a Delete vs Create dialema when you are dealing with both parent AND >> child variations in the local Dataset. >> >> Thanks for the link. >> >> -- >> Best Regards >> >> The Inimitable Mr Newbie º¿º >> >> >> "Bart Mermuys" <bmermuys.nospam@hotmail.com> wrote in message >> news:uTQ62ie7FHA.1184@TK2MSFTNGP12.phx.gbl... >>> Hi Mr Newbie, >>> >>> "Mr Newbie" <h***@now.com> wrote in message >>> news:OYz754R7FHA.1184@TK2MSFTNGP12.phx.gbl... >>>> 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/microsoft.public.dotnet.framework.adonet/browse_frm/thread/9fcf916b1247a77b/5c11a31b0eeb225e?lnk=st&q=%2Bacceptrejectrule+%2Bcascade&rnum=2&hl=nl#5c11a31b0eeb225e >>> >>> HTH, >>> Greetings >>> >>>> >>>> >>> >>> >> >> > > 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.  |
|||||||||||||||||||||||
Other interesting topics