John W. Colby
jcolby at colbyconsulting.com
Sat Feb 1 13:58:00 CST 2003
Ahhh, so referential integrety wasn't set up at all, allowing the "parent" to be deleted without the child being affected. 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: Saturday, February 01, 2003 1:16 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] Estimating Help 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. ----- Original Message ----- From: "John W. Colby" <jcolby at colbyconsulting.com> To: <accessd at databaseadvisors.com> Sent: Saturday, February 01, 2003 10:47 AM Subject: RE: [AccessD] Estimating Help > >Rows in related tables began disappearing from reports etc. and only then > did I realize that I had forgotten to prevent deletes from that table in the > event of any related row in any other table. My fault, of course! But we so > rarely lost employees that it took months and months to crop up. > > This is the reason that I never turn on cascade delete. It is off by > default so I just never turn it on! > > 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: Saturday, February 01, 2003 10:21 AM > To: accessd at databaseadvisors.com > Subject: Re: [AccessD] Estimating Help > > > Nice formula. Obviously the MF is the critical. I once read of a > data-cleansing study in Framingham, MA where they found the city name > "Boston" spelled 19 different ways! I'm not sure how that is possible, given > that people are generally trying to get it right rather than simply > shuffling letters into new positions, but there you go. > > There are RI issues, too. In my most recent app I neglected to nail one RI > rule down completely, and only discovered it months later. It was possible > to delete a row from the Employees table. Rows in related tables began > disappearing from reports etc. and only then did I realize that I had > forgotten to prevent deletes from that table in the event of any related row > in any other table. My fault, of course! But we so rarely lost employees > that it took months and months to crop up. > > A. > > ----- Original Message ----- > From: "Tom Adams" <tomadatn at bellsouth.net> > To: <accessd at databaseadvisors.com> > Sent: Friday, January 31, 2003 4:44 PM > Subject: Re: [AccessD] Estimating Help > > > > Here's the formula ... patent pending, top secret, do not disclose > > on penality of taking away your PC and making you use a Mac plus > > watch Survior, Class Reunion and Joe Millionaire. > > > > > > Hours per table = MF * NF * NR * EDF > > Add all the hours per table to get total hours > > > > MF = Mess factor (1 or greater) > > (How messy this junk is. > > Can you do a quick review and do batch corrects? > > Can you do some batch converts. > > Do you have to manually decipher multiple fields entered > > into one field and parse them to correct fields?) > > > > NF = Number of fields you have to check. > > > > NR = Number of rows you have to check. > > > > EDF = Experimentally determined factor > > (Theoretically less than 1) > > > > In practice it could take 1/2 day to weeks. It depends. > > > > I usually work with knowledgable users to analize, list the types > > of problems, and figure out how to correct each one. > > > > I rely on the users to do the manual deciphering/correcting (they know > > the data a lot better than you ever will.) > > > > You might try providing a sample table with list of problems to correct > > and get group feedback on times. > > > > However, since the monkeys won in our recent group joke contest > > you might just tell the customer you'll have to work by the hour as > > this kind of stuff can not be estimated. > > > > > > > > > > > > ----- Original Message ----- > > From: "Jeff Barrows" <outbak at wi.rr.com> > > To: <accessd at databaseadvisors.com> > > Sent: Friday, January 31, 2003 2:10 PM > > Subject: RE: [AccessD] Estimating Help > > > > > > > OK, I think I have continued to confuse everyone. > > > > > > All I want / need to know is if anyone has a formula for estimating time > > > to clean the garbage out of the database tables. The Archive question > > > has already been taken care of. I just want to know, for example, if > > > you figure the rate at 1 hour per table, if you consider the number of > > > records, the number of fields in each table, etc. > > > > > > Ultimately, I am trying to 'start' enforcing required fields and > > > referential integrity with an eye at porting out to SQL in the 'near' > > > future. > > > > > > Jeff Barrows > > > Outbak Technologies, LLC > > > Racine, WI > > > Phone: (262) 634-0653 > > > Mailto: jeff_developer at hotmail.com > > > www.outbak-technologies.com > > > ICQ # 8739060 > > > > > > _______________________________________________ > > > 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