Arthur Fuller
artful at rogers.com
Mon Feb 3 07:10:00 CST 2003
Hee hee hee. In truth, my favourite is Cascade Randomly Delete. ----- Original Message ----- From: "John W. Colby" <jcolby at colbyconsulting.com> To: <accessd at databaseadvisors.com> Sent: Monday, February 03, 2003 7:49 AM Subject: RE: [AccessD] Cascade-delete (was: Estimating Help) > >I use cascade frequently delete > > I have never used that option. I occasionally use Cascade Seldom Delete, > but usually Cascade Never Delete. Once in a great while Cascade Always > delete. > > John W. Colby > Colby Consulting > www.ColbyConsulting.com > > -----Original Message----- > From: accessd-admin at databaseadvisors.com > [mailto:accessd-admin at databaseadvisors.com]On Behalf Of Arthur Fuller > Sent: Monday, February 03, 2003 7:23 AM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] Cascade-delete (was: Estimating Help) > > > 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 > > _______________________________________________ > 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