quote:Originally posted by method
well i do not want to vilote the db reletionship so i do not want to user cascade delete.
Method, I think you missed the point of cascade deletes. If you build tables that are related but do not place foreign keys on them you run the risk of deleting parent rows and leaving orphaned child rows. So you add on foreign keys. Of course, now you have relationship integrity. If you want to delete parent rows you must delete the child rows first in order to avoid violation of the relationship.
The whole intent for cascading deletes is to allow you to support referential integrity thru foreign key relationships but allow you to delete parent rows without having to worry about first deleting the child rows. The cascade delete does this for you.
You have to ask yourself the question: "Is it acceptable for a user to delete something that has dependant information that will also be deleted?"
There are often cases where the answer is NO because you need to maintain some history of information (ex. Product Orders). Then you have to design your database to support additional conditions on the tables such as adding an "Active" field to a "Products" table to indicate that the product is or is not active any more. That way your application can see the row still exists but we shouldn't include it in lists of active products. In this case, you would not want cascade delete on the foreign key to the Products table because you want the database to error out if you DID try to delete a product that had order history.
So in the end you are back to the suggestion Jim made which is to
A) Query the database and see if circumstances prevent a valid delete
B) Try the delete and catch the Sql exception