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

Arthur Fuller artful at rogers.com
Mon Feb 3 06:27:00 CST 2003


Speaking only for myself, I use cascade frequently delete, wherever it's
appropriate. When I began this thread, I didn't mention cascade delete at
all. I very specifically said "rows disappearing from reports" -- not from
tables. This was an RI issue, not a cascade issue. However, since I have
been known to rant, carry on :-)

----- Original Message -----
From: "Drew Wutka" <DWUTKA at marlow.com>
To: <accessd at databaseadvisors.com>
Sent: Sunday, February 02, 2003 9:14 PM
Subject: RE: [AccessD] Cascade-delete (was: Estimating Help)


> Good post.  Kudos...couldn't agree more.
>
> Drew
>
> -----Original Message-----
> From: Susan Harkins
> To: accessd at databaseadvisors.com
> Sent: 2/2/03 5:20 PM
> Subject: Re: [AccessD] Cascade-delete (was: Estimating Help)
>
> Guys, does it really matter which process you trust the most -- your own
> or
> the system's? The truth is, both are flawed. :) The best any of us can
> do is
> choose one, learn it upside down and backa*sward, use it as efficiently
> and
> effectively as we know how and prepare for the worst.
>
> For the life of me, I don't see how you guys get into these good,
> better,
> best scenarios. What's best is what we know the best, and what costs the
> client the least time and money. And don't take that to mean I think
> it's OK
> to build a database in Excel just because Excel is your tool of choice
> --
> I'm not talking extremes -- I'm talking about Access and database
> programming practices in general.
>
> The discussion's interesting -- I've enjoyed the reasons for and
> against.
> Just don't think one way is any better than any other -- when all things
> being equal, the developer knows what he or she is doing.
>
> Susan H.
>
>
> > High User Count.
> >
> > Drew
> >
> > -----Original Message-----
> > From: Gustav Brock
> > To: Drew Wutka
> > Sent: 2/2/03 5:47 AM
> > Subject: Re: [AccessD] Cascade-delete (was: Estimating Help)
> >
> > Hi Drew
> >
> > > I know what you are saying though, so I can't argue the logic.
> > However, I
> > > would be far less resistant to letting a Server side DB do things
> like
> > that
> > > for me, then a Client Side db.  Don't get me wrong, I love Access.
> In
> > fact
> > > I like to push Access to the limits, and beyond when I can get away
> > with it.
> > > However, in doing so, I need it to be lean.
> >
> > If you are talking about a Jet backend, how can it be more or less
> > "lean"?
> > The frontend or middle-tier will be more lean if you let the backend
> > do the dirty work it is designed for.
> >
> > > I certainly have NOTHING against using tools like RI, or bound
> forms,
> > etc.
> > > In fact, on occasion, I use them myself.  However, most of the stuff
> I
> > do is
> > > designed for relatively heavy use, so I keep Jet doing only data
> > > reads/writes.  I don't want it doing anything else.  But that is
> just
> > the
> > > stuff I am working on.  Everyone has their own 'markets' or customer
> > base,
> > > and thus their own development 'traits'.
> >
> > That's your choice, of course. I'm not quite sure, however, what
> > "heavy" means? Is it size or multiple connections (users)? In that
> > case I see no idea in not letting the Jet engine do the heavy work it
> > is designed for; actually you'll experience that it - when RI is
> > enforced - will work faster when you do operations on related tables.
> >
> > /gustav
> >
> > _______________________________________________
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> > _______________________________________________
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> >
>
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
> _______________________________________________
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com




More information about the AccessD mailing list