It depends on your scenario.  In most cases, the BusinessLayer/DataLayer will handle this.  There are only a few rare instances where you would have to execute these two updates separately.  In fact, I cannot think of more than one time in all of these years where I had a situation that was complex enough that I had to "hand-code" the delete and inserts separately.  Have you tried this very scenario in your environment?  The BOs and DAL have a ton of logic handling these very types of situations.

Thank you, Trent. I can see this from the documentation.



But, suppose the parent table also has records marked for deletion as well as new records to be added. When are the deletion records sent to the db? If they're sent at the same time as the new records are added, then FK constraints may be violated.

If you have the relationships setup between the BOs it will already handle this for you.  SF BOs will manage the foreign key contraints for you, so even if in code, you try to save a child when the parent is a new record, it will first force the parent to save and then propogate the newly obtained PK to the children automatically.

If you do not have a relationship setup, then you will need to do this manually. 

Is there a way to specify the order of inserts/updates/deletes used for saving changes across multiple BO's?



Suppose I have multiple tables (Parent, Child, Grandchild) with database-side FK constraints. I might want inserts to be handled top-down (Parent->Child->Grandchild) and deletes bottom-up (Grandchild ->Child->Parent) in order not to violate the FK constraints.



What's the best way to handle this in the general case?