[AccessD] Estimating Help

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






More information about the AccessD mailing list