Sigfried,
if you know that your trigger will delete all children, I would suggest that you don't do a cascading delete in your bizobjs after deletion of the parent.
After the delete of your parent I assume that the record pointer is on another resord or that you read another record from the database. So requerying the parent should bring all children in line again. But you would have to do a cascading TABLEREVERT(.t.) for all your child bizobjs before you do the cascading requery.
Does this make sense?
Armin
>I need some help wraping my brain around how to handle this situation.
>
>I'm working on a system that uses either foxpro or SQL data.
>
>I'm using the bizness objects pretty heavely and I have a fairly heavy hierarchy of objects in a perticular part of the application. We delete the parent object, and in doing so delete the children as well. I've got cascading saves on for this hierarchy (because its needed when saving of course!) I also have some code in my bizness objects that are cascading deletes in the views. The database enforces data integrity with triggers on most of the relationships, but in a sense so does this part of the application.
>
>In foxpro all this works swimmingly. In SQL there is a problem. When saving the bizness objects a parent will save, the changes are sent to the sql server, and the database triggers delete the child records. When the parent bizness object cascades and tries to save its children the table updates fail when there are child reccords in the views, because the database has already deleted them, it causes an update error saying (another user has already changed the data etc etc...) In foxpro this dosn't happen because although they are deleted the reccords are still there (deleted), but in SQL they are gone for good and it can't update that reccord.
>
>I can't stop cascading saves because I need to save changes other than deletes in child tables in this process. I could get rid of the triggers but I'm striping down the data integrity on the database this way. Not cascading the deletes in the model dosn't work either because it would still be trying to update reccords that no longer exist, just not deleting them.
>
>The only other thing I can think of is to do the save cascading on the children before saving the parent, but that would be a big change to the framework classes, I'm not sure how wise it would be.
>
>Anyone (Kevin especialy) have any other ideas I'm missing here? Has anyone dealt with this problem? I don't see how to avoid it without changing the database or the framework.
