John W. Colby
jcolby at colbyconsulting.com
Sat Feb 1 09:48:00 CST 2003
>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