[AccessD] Cascade-delete (was: Estimating Help)

I'm paranoiac about this kind of thing, but have implemented it myself on
occasion. In my big app, for example, there are times when people want to
delete a sale, and with it the rows in several child tables. Cascade delete
is turned off, but I have a stored procedure that accepts a SaleID and does
the nasty. The only person in the firm with rights to that sproc is me. Its
only purpose is to nuke my own test sales easily.
Another sproc, which Access invokes by password only, moves a given sale
from Sales + its kids to a set of history tables.
Frankly, I see the deletion of data as a symptom of a design flaw and/or a
bad accounting practice. Suppose you have a button that cancels an order
(deletes it and its kids). How will you ever notice a pattern if you
actually delete the data? Suppose some enterprising employee figures out a
way to defraud the company by placing and then canceling orders? Suppose
there's something stupid about the UI that causes people to screw up sales
and have to cancel them frequently? With the data gone all you have is vague
subjectivity.
My $.02
A.

-----Original Message-----
From: accessd-admin at databaseadvisors.com
[mailto:accessd-admin at databaseadvisors.com] On Behalf Of Rocky Smolin -
Beach Access Software
Sent: February 8, 2003 11:07 AM
To: accessd at databaseadvisors.com
Subject: Re: [AccessD] Cascade-delete (was: Estimating Help)

I come a bit late to this thread (but that's not new for me).  I've tried to
follow it but it ain't always been easy.  I am using cascade delete in an
app for a client who rents audio visual equipment and am wondering if this
is good design runs afoul of anybody's catechism on the subject:

The Rental Agreement header has one to many relationship with several table
:
     Equipment to be rented (with one-to-one with a CheckIn/CheckOut table)
     Items sold at retail
     Labor
     Sub-Rental Header (with its own detail records

might be more - I forget.  So in order to delete a rental agreement (which
they want to do from time to time) either they have to go in and delete all
the detail records first, or I give them cascade delete.  They opted for
cascade delete.

I do give them a very clear warning message about what's going to be deleted
and have them confirm.

What say you all to this?

Rocky Smolin
Beach Access Software

P.S. I though everybody was used to Colby's rhetorical style by this time.
He's been quite - well relatively - civil on this subject. Try him on the
phrases 'unbound form' and 'natural key'.  From a distance, of course. :)

----- Original Message -----
From: "John W. Colby" <jcolby at colbyconsulting.com>
To: <accessd at databaseadvisors.com>
Sent: Wednesday, February 05, 2003 10:39 AM
Subject: RE: [AccessD] Cascade-delete (was: Estimating Help)


> Aww grow up guys.
>
> I never said never.  I stated very plainly that if everyone has the right
to
> delete the records then it doesn't matter.  John then states (finally, in
> the last email) that this is the case.  So it doesn't matter (in this
case).
>
> So where exactly is the beef?
>
> I don't give a rat's patuty if you turn on cascade delete for every table,
> every time, in every database.  To search around struggling to find
exactly
> the instance where it is useful is a waste of everyone's time.  If it
works
> for you, and you don't get fired when records disappear who really cares.
> In any event, you can always blame the user after all.  "Hey, I warned
> them".
>
> In any case, I certainly don't care, it isn't my database, nor my job on
the
> line.  And I am not getting my users fired for not doing my job correctly.
>
> Sorry if that was "derisive" but really, look at what I said.  I was very
> very VERY clear in my statements.  And I see no reason to modify any of
> them.
>
> John W. Colby
> Colby Consulting
> www.ColbyConsulting.com
>


_______________________________________________
AccessD mailing list
AccessD at databaseadvisors.com
http://databaseadvisors.com/mailman/listinfo/accessd
Website: http://www.databaseadvisors.com