A Microsoft Office (Excel, Word) forum. OfficeFrustration

If this is your first visit, be sure to check out the FAQ by clicking the link above. You may have to register before you can post: click the register link above to proceed. To start viewing messages, select the forum that you want to visit from the selection below.

Go Back   Home » OfficeFrustration forum » Microsoft Access » Using Forms
Site Map Home Register Authors List Search Today's Posts Mark Forums Read  

Calculated field in Forms



 
 
Thread Tools Display Modes
  #11  
Old April 23rd, 2010, 07:06 PM posted to microsoft.public.access.forms
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Calculated field in Forms

On Fri, 23 Apr 2010 10:39:02 -0700, dar wrote:

John i forgot the other fields

Table: Employee
LName
FName
Hire Date
Office Staff 30 days for eligibilty from hire date
Transport 30 days for eligibility from hire date
Manager 30 days for eligibility from hire date
Maint 30 days fro eligibilty from hire date
Clerk 90 days for eligibility from hire date


This isn't making sense. Does each employee have a Office Staff field, a
Transport field, a Manager field??? What is contained in this field - a date?
If an employee is a clerk, why does she need a Transport field?

--

John W. Vinson [MVP]
  #12  
Old April 23rd, 2010, 07:53 PM posted to microsoft.public.access.forms
Dar
external usenet poster
 
Posts: 86
Default Calculated field in Forms

I have created a field labeled; HireDate30 and HireDate90 and would like to
calculate the eligibility date based off of the HireDate30 and HireDate90. I
think that would make is simpler than trying to calculate it off of the
titles, right?

Thank you

"John W. Vinson" wrote:

On Fri, 16 Apr 2010 09:32:01 -0700, dar wrote:

Yes, managers are 30 days from hire date, clerks are 90 days from hire date.


That's a business rule.

It's not a database rule.

I can see how you would enforce that in your office, but since you have chosen
not to post any information about your tables, I cannot tell how you would
enforce it in a database.

I'd love to be able to help, but I can't unless you tell me what's in your
database!
--

John W. Vinson [MVP]
.

  #13  
Old April 23rd, 2010, 08:29 PM posted to microsoft.public.access.forms
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Calculated field in Forms

On Fri, 23 Apr 2010 11:53:01 -0700, dar wrote:

I have created a field labeled; HireDate30 and HireDate90 and would like to
calculate the eligibility date based off of the HireDate30 and HireDate90. I
think that would make is simpler than trying to calculate it off of the
titles, right?


Again:

What is the datatype of hiredate30 and hiredate90?
Does every employee have a Hiredate30 and also a Hiredate90?
If so why?

I really think you may be misunderstanding how tables work. They're not
spreadsheets! A Table represents a particular type of Entity - real-life
person, thing or event. Each Field in the table contains the value of some
specific Attribute of that entity - the person's FirstName, their LastName,
their HireDate, their PositionID and so on. If you have several mutually
exclusive attributes (i.e. if someone has a Hiredate30 then their Hiredate90
must be blank), your table structure is wrong.

I don't understand your business model, but if you'll allow me to grope in the
dark with a possible idea... consider the following tables:

Employees
EmployeeID autonumber primary key
LName
FName
HireDate
PositionID

Positions
PositionID autonumber primary key
Position e.g. Clerk, Manager, High Muckamuck
DaysToEligibility

You could then create a query joining these two tables and calculate the
eligible date. The SQL view of the query (copy and paste it into a new query's
SQL view) would be

SELECT LName, FName, DateAdd("d", [DaysToEligibility], [HireDate]) AS
DateEligible
FROM Employees INNER JOIN Positions
ON Employees.PositionID = Positions.PositionID;

You can put criteria on the DateEligible calculated field if that's what
you're trying to do.
--

John W. Vinson [MVP]
  #14  
Old April 23rd, 2010, 09:08 PM posted to microsoft.public.access.forms
Dar
external usenet poster
 
Posts: 86
Default Calculated field in Forms

On my last post I changed it so that I would not have to create each title.
I have created the following feilds; HireDate30 and HireDate90

"John W. Vinson" wrote:

On Fri, 23 Apr 2010 10:39:02 -0700, dar wrote:

John i forgot the other fields

Table: Employee
LName
FName
Hire Date
Office Staff 30 days for eligibilty from hire date
Transport 30 days for eligibility from hire date
Manager 30 days for eligibility from hire date
Maint 30 days fro eligibilty from hire date
Clerk 90 days for eligibility from hire date


This isn't making sense. Does each employee have a Office Staff field, a
Transport field, a Manager field??? What is contained in this field - a date?
If an employee is a clerk, why does she need a Transport field?

--

John W. Vinson [MVP]
.

  #15  
Old April 23rd, 2010, 09:14 PM posted to microsoft.public.access.forms
Dar
external usenet poster
 
Posts: 86
Default Calculated field in Forms

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.

"John W. Vinson" wrote:

On Fri, 23 Apr 2010 11:53:01 -0700, dar wrote:

I have created a field labeled; HireDate30 and HireDate90 and would like to
calculate the eligibility date based off of the HireDate30 and HireDate90. I
think that would make is simpler than trying to calculate it off of the
titles, right?


Again:

What is the datatype of hiredate30 and hiredate90?
Does every employee have a Hiredate30 and also a Hiredate90?
If so why?

I really think you may be misunderstanding how tables work. They're not
spreadsheets! A Table represents a particular type of Entity - real-life
person, thing or event. Each Field in the table contains the value of some
specific Attribute of that entity - the person's FirstName, their LastName,
their HireDate, their PositionID and so on. If you have several mutually
exclusive attributes (i.e. if someone has a Hiredate30 then their Hiredate90
must be blank), your table structure is wrong.

I don't understand your business model, but if you'll allow me to grope in the
dark with a possible idea... consider the following tables:

Employees
EmployeeID autonumber primary key
LName
FName
HireDate
PositionID

Positions
PositionID autonumber primary key
Position e.g. Clerk, Manager, High Muckamuck
DaysToEligibility

You could then create a query joining these two tables and calculate the
eligible date. The SQL view of the query (copy and paste it into a new query's
SQL view) would be

SELECT LName, FName, DateAdd("d", [DaysToEligibility], [HireDate]) AS
DateEligible
FROM Employees INNER JOIN Positions
ON Employees.PositionID = Positions.PositionID;

You can put criteria on the DateEligible calculated field if that's what
you're trying to do.
--

John W. Vinson [MVP]
.

  #16  
Old April 23rd, 2010, 09:44 PM posted to microsoft.public.access.forms
John W. Vinson
external usenet poster
 
Posts: 18,261
Default Calculated field in Forms

On Fri, 23 Apr 2010 13:14:11 -0700, dar 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]
  #17  
Old April 23rd, 2010, 10:49 PM posted to microsoft.public.access.forms
Dar
external usenet poster
 
Posts: 86
Default Calculated field in Forms

Thank you I will try that.

"John W. Vinson" wrote:

On Fri, 23 Apr 2010 13:14:11 -0700, dar 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]
.

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is Off
HTML code is Off
Forum Jump


All times are GMT +1. The time now is 09:35 PM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
Copyright ©2004-2024 OfficeFrustration.
The comments are property of their posters.