jimdettman at verizon.net
Tue May 1 14:42:03 CDT 2018
That's why I'd rather go for the detail and summarize<g>
Plus, you never know when and what else you'll be asked to track. What if
someone takes a half day off for jury duty?
From: AccessD [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of
Sent: Tuesday, May 1, 2018 2:22 PM
To: Access Developers discussion and problem solving
Subject: Re: [AccessD] Payroll
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!
On Mon, Apr 30, 2018 at 6:54 PM, Stuart McLachlan <stuart at lexacorp.com.pg>
> 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
> Website: http://www.databaseadvisors.com
AccessD mailing list
AccessD at databaseadvisors.com
More information about the AccessD