|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
(Q for David Sceppa!) Problems submitting hierarchical changes to DBOn page 786 of the ADO.NET Core Reference (chapter 11 - Advanced Updating Scenarios), David Sceppa gives the basic steps for submitting hierarchical changes (paraphrased): 1. Submit new master rows 2. Submit new detail rows 3. Submit modified master rows 4. Submit modified detail rows 5. Submit deleted detail rows 6. Submit deleted master rows I took this process and applied it to a rather large, normalized data structure. However, the modified detail row changes would never make it to the database. I stepped through the code and found that after updating the modified master rows (step 3), the related detail rows' RowState would change from Modified to Unchanged. This, of course, keeps the detail rows from being sent to the database. After swapping steps 3 and 4, the database was successfully updated. My questions...why does that happen in the first place? Will swapping steps 3 and 4 have some other adverse effect? Thank you! Eric Eric,
It sounds like you set the AcceptRejectRule property on your ForeignKeyConstraint to Cascade rather than the default of None. The DataAdapter implicitly calls AcceptChanges on a row after successfully submitting a pending change. When you set this property to Cascade, that call cascades down to the related rows, leading to the behavior you described. I hope this information proves 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. Thank you, David.
I had the misconception that the AcceptRejectRule set to Cascade would cascade only changed FK values. (For example, if the master table's PK column changes for some reason, it would update all detail FK columns with that value.) However, actually typing out that last statement makes me realize how truly illogical that train of thought is. Thanks again! Eric. Show quote "David Sceppa" <davi***@online.microsoft.com> wrote in message news:vIJltfTOFHA.5096@TK2MSFTNGXA01.phx.gbl... > Eric, > > It sounds like you set the AcceptRejectRule property on your > ForeignKeyConstraint to Cascade rather than the default of None. The > DataAdapter implicitly calls AcceptChanges on a row after successfully > submitting a pending change. When you set this property to Cascade, that > call cascades down to the related rows, leading to the behavior you > described. > > I hope this information proves 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. > Eric,
No worries. It happens to the best of us. I believe the property you were looking for was ForeignKeyConstraint.UpdateRule, which is set to Cascade by default to provide the behavior you're looking for. 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. |
|||||||||||||||||||||||