Prev: IIf statement to show A, B, C
Next: Object or class does not support set of events
From: John W. Vinson on 23 Apr 2010 16:44
On Fri, 23 Apr 2010 13:14:11 -0700, dar <dar(a)discussions.microsoft.com> wrote:

>I have either an employee who will qualify in 30 and other in 90 days. When
>the data entry person enters the information she will either enter their hire
>date in the HireDate30 or the HireDate90. Based off of the Hire date info i
>want it to calculate in the BenifitsEligibilityDate.

Sorry, but that's INCORRECT DESIGN.

The person's hire date is their hire date, and it should be in the HireDate
field... and noplace else.

You need to have in your database, somewhere, the information that will
distinguish a 30 day employee from a 90 day employee. I'm *guessing* that
information is implied by the position into which that employee is hired; that
guess was the source of my previous suggestion.

Rather than having two unnecessary and redundant fields in your table, just
store the 30 or 90 days someplace - in the positions table, in the employee
table, even just as a combo box on a form - and *CALCULATE* the
BenefitsEligibilityDate using DateAdd. It is unnecessary and inappropriate to
store that date in any table (unless you want to make exeptions, say to make
the boss's nephew eligible in three days instead of ninety).
--

John W. Vinson [MVP]
From: dar on 23 Apr 2010 17:49
Thank you I will try that.

"John W. Vinson" wrote:

> On Fri, 23 Apr 2010 13:14:11 -0700, dar <dar(a)discussions.microsoft.com> wrote:
>
> >I have either an employee who will qualify in 30 and other in 90 days. When
> >the data entry person enters the information she will either enter their hire
> >date in the HireDate30 or the HireDate90. Based off of the Hire date info i
> >want it to calculate in the BenifitsEligibilityDate.
>
> Sorry, but that's INCORRECT DESIGN.
>
> The person's hire date is their hire date, and it should be in the HireDate
> field... and noplace else.
>
> You need to have in your database, somewhere, the information that will
> distinguish a 30 day employee from a 90 day employee. I'm *guessing* that
> information is implied by the position into which that employee is hired; that
> guess was the source of my previous suggestion.
>
> Rather than having two unnecessary and redundant fields in your table, just
> store the 30 or 90 days someplace - in the positions table, in the employee
> table, even just as a combo box on a form - and *CALCULATE* the
> BenefitsEligibilityDate using DateAdd. It is unnecessary and inappropriate to
> store that date in any table (unless you want to make exeptions, say to make
> the boss's nephew eligible in three days instead of ninety).
> --
>
> John W. Vinson [MVP]
> .
>
First  |  Prev  | 
Pages: 1 2 3 4
Prev: IIf statement to show A, B, C
Next: Object or class does not support set of events