Quick question -

Using adapter: when deleting multiple entities using UnitOfWork2 - how do you trap delete exceptions (i.e., referential integrity) on an entity-by-entity basis. I need to be able to handle each delete separately.

Thanks.

Jeff

the order in which you add entities to be deleted is the order in which they are actually deleted. So if you make the order correct, the delete will succeed.

Otis wrote:

the order in which you add entities to be deleted is the order in which they are actually deleted. So if you make the order correct, the delete will succeed.

I'm not sure that you understood my question. Upon UOW group deletion, some entities will success and others will fail based on the database settings for RI. I need to be able to capture the individual exceptions on an entity-by-entity basis.

Jeff

That's not possible. A delete which violates an FK is such a severe error that for example SQLServer aborts any transaction which is going on. So it will always fail on the first entity which isn't correctly ordered.

Otis wrote:

That's not possible. A delete which violates an FK is such a severe error that for example SQLServer aborts any transaction which is going on. So it will always fail on the first entity which isn't correctly ordered.

Let me try to understand, because this has significant design implications. For example, an AccountEntity has an associated EmployeeEntityCollection. Using UOW2, I select five employees to be deleted. Four of the employees DO NOT have associated timecard transactions posted against them and therefore, SQLServer allows them be deleted. The fifth employee HAS associated timecard transactions and SQLServer fails when attempting the delete (RI setting in SqlServer).

Now, if there was a way to handle each EmployeeEntity deletion individually, then we might allow the four employee records to be deleted and communicate back to the user the one employee that could not be deleted.

If there is no way to communicate individual entity exceptions back to the user, then the entire transaction would fail and the user wouldn't know which employee record caused the failure.

How do I design around that?

Thanks. Jeff

You would have to loop through it manually and delete the entities directly. Then if an individual entity failed you would know exactly which one it was.

That I understand. How do I "loop through it manually"? Does this mean that I can't use UOW2?

I need to be able to handle each delete separately

Does this mean that I can't use UOW2?

If the first statement is true, then the answer to the second one is Yes

How do I "loop through it manually"?

Don't add the entities to the UOW, just delete them one by one. you may add then to an EntityCollection to be deleted later, and then when their time comes, loop inside the collection and call DeleteEntity on each one of them.

Manually deletes are prefered in this situation because they won't terminate your UoW transaction when some delete fails, which is what you want: no termination of the transaction. Be aware of the fact that the dbms can also terminate a transaction on an error. Sqlserver does this when a level20 (could be level 16, but I thought it was level 20) or higher error is raised.

Thank you, guys!