Results 1 to 5 of 5

Thread: Colonizing a table of employees from a table of applicants in Microsoft Access

  1. #1
    Join Date
    Nov 2010
    Posts
    30

    Colonizing a table of employees from a table of applicants in Microsoft Access

    I maintain tabs on each and every applicant, and sometimes I even appoint one, so I require entering a great number of the information in excess of another time, generating an opportunity for errors. So what is necessary to make use of the application table and colonize the employee table? Please suggest some idea or some information about how to generate this table.

  2. #2
    Join Date
    Nov 2008
    Posts
    1,192

    Re: Colonizing a table of employees from a table of applicants in Microsoft Access

    So utilize your two tables but insert an EmployeeID and HireDate to the Applicants table. Make certain that your Employee table has an index set to no replacement or duplicate on EmployeeID. While applicatant is appointed fill in EmployeeID and HireDate. Make use of an append query to insert fresh employees to the Employee table. Try this and let me know this is useful to you or not?

  3. #3
    Join Date
    Jun 2009
    Posts
    1,518

    Re: Colonizing a table of employees from a table of applicants in Microsoft Access

    What you have at this point is a type and two sub types. Persons is the type, Applicants and Employees are the sub types. A suitable model would be a Persons table with primary key PersonID, and Applicants and Employees tables, another time with primary keys PersonID. The relationship from persons to Applicants and Employees is in every case one-to-one. On the other hand, that if PersonID in Persons is an autonumber it cannot be in Applicants and Employees; it have to be a simple long integer number data type. Note that a one-to-one relationship is nonetheless directional and have to be shaped consequently.

  4. #4
    Join Date
    Nov 2008
    Posts
    1,514

    Re: Colonizing a table of employees from a table of applicants in Microsoft Access

    I think It really doesn't issue if they split a business relationship or not. The easy fact is that people share one main relationship, we are all people. Amassing 'people' in a 'people' table is the most competent way to store that information despite of the business rules which handle it. You have to build the distinction between the data layer and the business layer. If you don't wish to act together with their records on a daily basis, then don't; generate a user interface to prohibit them on a daily basis. But if they come back, you have their information and you don't require copying it. What about if a candidate becomes an employee or vice versa? What if anyone reapplies? With the model I recommend, you don't want to copy their information. In addition you can then present a few statistical bases for present and future business cleverness conclusions. If you wish to, you can occasionally run a defrayal schedule to get liberate of old candidate data. What I am talking about is the top way to store your data.

  5. #5
    Join Date
    Mar 2009
    Posts
    1,360

    Re: Colonizing a table of employees from a table of applicants in Microsoft Access

    In this case I mean in your case I also want to add something which maybe like you or useful to you in your work. From a with the sole purpose data modeling viewpoint, a person is a person, not considering of whether they are a candidate, an employee, a CEO or a dealer contact. I would suggest you to generating a Person table, and afterward add attributes to designate what relationship they have to the company.

Similar Threads

  1. Replies: 5
    Last Post: 27-08-2011, 10:53 AM
  2. Link a Table to another Table to Drop Down In Main Table
    By himeshRES in forum Windows Software
    Replies: 6
    Last Post: 11-12-2010, 01:01 PM
  3. Design view table in Microsoft access 2007
    By Balamohan in forum Windows Software
    Replies: 5
    Last Post: 08-01-2010, 03:41 AM
  4. Replies: 7
    Last Post: 26-11-2009, 11:31 PM
  5. Replies: 3
    Last Post: 16-09-2008, 04:46 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •