Does anyone use access as a database for managing job applicantio.

  • Thread starter TiffanyMichelleRecruiter
  • Start date
T

TiffanyMichelleRecruiter

I am working for a small business and would like to use Access as an
applicant tracking system. Has anyone used Access for this type of
application?
 
A

Al Camp

Tiffany,
If you're a "small" business, how many applications do you expect per week, per month?

If you do a high volume, Access would be the best application to handle that, but...

If your volume isn't that great, you might wnat to consider your application
"development" time, and the application "transcribing" time involved vs. just a simple
"paper" system to file applicantions in some hierarchical system. ("A" applicants, "B"
Applicants... etc...)
Or, a better solution would be to purchase an "off the shelf" application... ready to
go. Try the web for "canned" software prices before deciding which way to go. I'm sure
there are many available at very reasonable prices.

I'd give the same advice if you said you wanted a small business checking/accounting
program. Not worth the time to develop... just buy one.
 
M

MarieK

I am not exactly sure what you mean by tracking...but we use Access for our
HR database tracking various things for over 400 employees.
 
K

Khoriics

MarieK,

I am developing a HR database. What is the best way to enter dependent info
in a record and have it show as a list of names under an employee. And would
this be the same as showing the history of, lets say, a person's salary.

Thanks

khorii
 
J

John Vinson

I am developing a HR database. What is the best way to enter dependent info
in a record and have it show as a list of names under an employee. And would
this be the same as showing the history of, lets say, a person's salary.

Whenever you have a one to many relationship - one employee to many
dependents, or one employee to many salary values - you need *two
tables*. You do NOT enter dependent info into the employee record at
all!

Instead you have a Dependents table:

Employees
EmployeeID <Primary Key>
LastName
FirstName
<other static employee info>

Dependents
DependentID <Autonumber Primary Key, or SSN primary key if
appropriate>
LastName <no, you can't assume it's the employee's last name>
FirstName
Relationship
<other needed bio information>

Each dependent would be entered in a separate record, using a Subform
on the Employees form to enter and display the data.

John W. Vinson[MVP]
 
Top