[AccessD] Payroll

[Doug Steele]

One other thing I add from (bitter) experience is that, when you build a
time tracking system base on some kind of period (daily, weekly, monthly,
bi-monthly, bi-weekly), give some though to what you would need to do to
your code if the time period suddenly changes!

Doug

On Mon, Apr 30, 2018 at 6:54 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
wrote:

> At times, there are valid reasons for NOT normalising or for re-thinking
> what you actual mean
> by nromalisation.
>
> This is one of them.
>
> Think in terms of a TYPE or Object called a "PayPeriod"  rather than "Day"
> and D1Hours to
> D14Hours become separate attributes, not separate entities. :)
>
> I've built systems exactly like this in the past and in fact I'm doing
> another one right now.
>
> I doubt that there will ever be a fortnight with more or less days. :)
>
> If they decide to change to a different pay period, (weekly or monthly?)
> how you store daily
> attendance hours will be the least of your worries.
>
>
>
> On 30 Apr 2018 at 11:30, Bob Heygood wrote:
>
> > Rocky & Jim,
> > Yes I knew intuitively that I was breaking some normalization rules.
> > Just started to let the UI interface drive the schema.
> >
> > For data entry the user insists on being able to "tab" through a whole
> > pay period (2 weeks) for each employee and job.
> >
> > So, how do I use a table with only one record per day?
> > UNBOUND, I guess. And then via code stuff into a "proper"
> > table........ I have done so before but a lot work.
> >
> > Really don't need any other fields.
> >
> > Thanks for responding,
> >
> > Bob
> >
> >
> >
>
>
> --
> AccessD mailing list
> AccessD at databaseadvisors.com
> http://databaseadvisors.com/mailman/listinfo/accessd
> Website: http://www.databaseadvisors.com
>