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.

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?

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.

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.

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.