Rocky Smolin - Beach Access Software
bchacc at san.rr.com
Sun Feb 9 13:37:00 CST 2003
> Your method works fine, as long as they go in through your interface. If > they go around your interface, then they again gain the right to delete, > since "anyone can delete". Well, that's reassuring. Because anyone with the knowledge to go around my interface can certainly do enough damage with or without cascade delete. I had a user once who went around my interface. Created a query of almost every record in the database, deleted from the query all but the twelve she wanted, and ran a report. Well and good until I got a call that all the records except for twelve seemed to have disappeared from the database. I think the difference here is not one of programming technique but how much responsibility I feel I have to exercise to prevent users from doing stupid things. I go pretty far down that road but apparently, not as far as you. And how far I go also depends on the user and their desire for accessibility and flexibility vs. security. I think your car analogy is not valid. I don't see the liability issue as a good parallel. Just as a car manufacturer cannot make a car so safe that I cannot drive it into a wall, so programmers will not be sued if the user does something stupid. There is case precedent for this that goes back a couple of decades when, I believe it was Lotus that was sued by an engineering firm. It seems that the firm won a contract on a quote that was based on a spreadsheet where the user had put in the sum of a column but did not include all of the rows in the column that should have been in the sum. This reduced their expenses enabling them to create a winning, but unprofitable contract. The case was decided in favor of Lotus. Rocky ----- Original Message ----- From: "John W. Colby" <jcolby at colbyconsulting.com> To: <accessd at databaseadvisors.com> Sent: Sunday, February 09, 2003 10:51 AM Subject: RE: [AccessD] Cascade-delete (was: Estimating Help) > Rocky, > > Think of cascade delete off in the same way as setting up validation rules > in the table in the back end. A validation rule may say, "Age cannot be > less than zero". It doesn't matter how the user tries, they simply can't > enter an age less than zero. Enforced by Jet, for all users, all of the > time! > > Cascade delete off is a validation rule. "Do not allow deletes if the table > has children". I don't care who you are, I don't care how you try, I am not > going to allow you to delete the parent if it has children. Enforced by > Jet, for all users, all of the time, from any method of access! > > Your method works fine, as long as they go in through your interface. If > they go around your interface, then they again gain the right to delete, > since "anyone can delete". > > All you are doing by getting rid of cascade delete and doing it with queries > is raising the bar on the ability to delete. If I can get at your database, > and cascade delete is on, I can delete potentially thousands of records > simply by clicking on a single record and hitting delete. I can do that by > opening the BE directly, by linking in the tables to a new db, by creating a > vb interface and going at them using vb (or 'C', or anything else). I can > do it by getting at the database window in the FE. I can do it if I am > allowed to build queries in the FE. Etc. Etc. > > Turn off cascade delete and ALL of those avenues are cut off. Just like > that, with the stroke of a pen. > > Now I have to know enough to delete children, then delete the parent. I > have to know enough to build a query that pulls exactly the children for the > parent I want to delete. I have to know all of the child tables that belong > to that parent. Etc. Etc. > > Look at what cascade delete does and you see why turning it off is so > important. In a real database of mine, an insurance policy is related to N > claims. With cascade delete turned on, if anyone manages to tell Jet to > delete a policy, all of the related claims get deleted. Claims have contact > information, payments, expenses, attending physicians, and about 5 other > child tables. Deleting "one record" (the policy) could also delete dozens > of claims, and literally thousands of contacts, payments, expenses etc. > > That is disastrous!!! It doesn't matter if they weren't supposed to, it > doesn't matter if they were supposed to know better, it doesn't matter if > they were supposed to lock up their computer and throw away the key when > they went home. What matters is that if I turn on cascade delete, I AM > RESPONSIBLE for that data being deleted. I knew the damage that could be > done, and I turned it on anyway. The poor user who actually does the delete > and clicks yes without even reading the warning from Jet about deleting > related records is NOT responsible for the damage. I am! > > ONLY security will absolutely prevent some individual from doing the damage > if they are determined to do it, but cascade delete just hands the world the > key to deletes. > > 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 Rocky Smolin - > Beach Access Software > Sent: Sunday, February 09, 2003 11:07 AM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] Cascade-delete (was: Estimating Help) > > > John: > > I agree about the need for restricting the right to delete. My standard > approach to this, which I copy from one app to another, is to have the user > sign in with a password. My standard access rights are 1) read only, 2) > data entry, 3) admin. These levels can be easily modified or expanded to > fit a particular user's requirements. > > I even have one user who has the access controlled by field and function > within form, so that I had to design a (beautifully color coded) grid of > access rights. Which of course, requires admin level to access. > > So I can easily restrict the delete key to a user with only admin rights. > Once restricted however, I don't see the advantage of the multiple delete > query approach vs. the cascade delete. If a user has the right to delete, > does the method of deletion make a difference? > > Rocky > > > _______________________________________________ > AccessD mailing list > AccessD at databaseadvisors.com > http://databaseadvisors.com/mailman/listinfo/accessd > Website: http://www.databaseadvisors.com