Myles Wakeham wrote:

> I'm wondering if there is a 'best practice' for doing this. I have a
> database full of contact records. Of these, many have related tables of
> data that I can't delete the contact until those related records are
> re-assigned to other parties. Consequently a Cascade delete rule won't
> work here.
>
> But rather than giving the user the ability to 'try' to delete the
> record and be told that they can't because of a violation of a
> referential integrity rule, I'd like to be more pro-active with this and
> only give them a delete option of the contact record has no related data
> that would stop a delete from occuring.
>
> Is there is a good and fast way to determine if one of these records
> could be deleted other than giving the user the ability to try and then
> be told they can't? I'm basically trying to simplify their world a bit
> by being proactive and telling them up-front that a record can or cannot
> be deleted as it stands.
>
> All suggestions, comments, flames, etc. are actually greatly appreciated.
>
> Myles
>

I got your point, and I think it is good... but, I think you will do a
lot of checks for every record visited, and only a fraction of those
would be a candidate for deletion, so, perhaps you will slowdown the
navigation process for a few cases.

What you can do, is to catch the exception (FK violation) and put some
inteligence on your code to show the user why he could not delete this
particular record, and provide a way to reassign the childs to a new
parent on that warning dialog.

see you !

--
Alexandre Benson Smith
Development
THOR Software e Comercial Ltda
Santo Andre - Sao Paulo - Brazil
www.thorsoftware.com.br