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