John W. Colby
jcolby at colbyconsulting.com
Wed Feb 5 12:39:00 CST 2003
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 -----Original Message----- From: accessd-admin at databaseadvisors.com [mailto:accessd-admin at databaseadvisors.com]On Behalf Of Gustav Brock Sent: Wednesday, February 05, 2003 1:23 PM To: John Bartow Subject: Re: [AccessD] Cascade-delete (was: Estimating Help) Hi John Very well put. The funny part is that, if I recall correctly, JC was the first on this list to stress "never say never" on a very relevant topic. I have forgot which topic, but it doesn't matter as this statement is universal when it comes to practical database design. /gustav > Hi Gustav, > I quite responding to a thread when it gets too inflammatory. (Plus, Susan > implied that it was getting a bit out of hand.) When things get derisive I > know that no one is going to learn anything. I learned a long time ago that > some people see things in binary tone and some people see them in continuous > tone. I've been working in the computer field since 1979 and while that > certainly doesn't make me an expert at anything it does give me a bit of > experience. Deriding my physical or mental work habits because I have an > opposing view isn't going to change my mind on an issue. Debating and > discussing with someone who is knowledgeable, experienced and of a different > opinion may well expand the possible solutions that my mind can formulate. > The way I look at it there's always more than one way to do anything. To me > its a matter of finding the best solution for each situation. In that > respect, I disagree with people of the binary tone viewpoint - but I still > respect them :o) > As far as cascade delete goes, I tend to agree with many issues covered in > the thread. I do take exception to the word "never". Just as I would > disagree with saying never to bound/unbound forms or natural/autonumber > keys. There is always an exception to every rule so instead I view them as > "guidelines". In the particular situation I sited, I think cascade delete > fits the bill much better than using code or queries to delete the child > records. The parent record WAS able to be deleted by "anyone" using the DB. > The records were used for formulating ideas or "scenarios" and left in the > table to avoid having to recreate the same scenario at a later date. Only 1 > would be chosen and used for any particular case. So essentially the records > not chosen could be viewed later and certain parameters could be modified > for more "brainstorming" scenarios, thus preventing the NEED to re-enter of > bunch of mundane detail data. It is one example where using an Access DB is > actually more powerful than some major DBs because I don't have to specify > that every program using the BE DB must write procedures to clean up these > unused child records when deleting a un-chosen scenario. The reality of the > situation is that just because someone has a degree and/or experience using > a GIS doesn't mean they understand relational databases, Access queries or > VB code. Until recently the major GIS platform used in the USA used a flat > file database and an application specific macro language. Now we're pushing > and pulling MBs of spatial data into and out of Access DBs and using VBA! > Cascade Delete certainly can be dangerous but like someone famous once said: > "with great power comes great responsibility"! > John B. > "In Wisconsin, in the winter, in my office, in the basement... > nothing is black and white here." > -----Original Message----- > From: accessd-admin at databaseadvisors.com > [mailto:accessd-admin at databaseadvisors.com]On Behalf Of Gustav Brock > Sent: Wednesday, February 05, 2003 5:55 AM > To: Arthur Fuller > Subject: Re: [AccessD] Cascade-delete (was: Estimating Help) > Hi Arthur >> 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 :-) > Hmmm ... nice try. And it brought some relief. > But [picky mode on] you did start the thread - I couldn't read this in > more than one way: >> I didn't mean that the rows were disappearing, but rather that they >> disappeared from reports, since their FK referents were gone. I would >> never >> be so foolish as to turn cascade-delete on anywhere in any serious >> database :-) >> I restored an old copy with the deleted employees, then imported the >> rows and restored sanity to the db. > /gustav _______________________________________________ AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com