|
|
|
|
After using TRACCESS for a while, especially if more than one TRACCESS Administrator is working on the database, there is the tendency to accumulate duplicate objects. The most important objects in the TRACCESS database are Employees and Tasks. There may be several reasons why duplications may occur over time:
For Employees
Contractors who work for brief periods and whose training was tracked in the main database. If this contractor worked for a few months one year, another few months another year, their accounts may have been created as new each time they came back to the organization.
Employees who go from one division or area of the organization to another. In this case, they may be created once in one organization unit, then recreated in another.
For companies who have had more than one TRACCESS database at a time. When the databases become merged as one, some employees may have existed in both original databases and in turn get different accounts.
For people who "go by" more than one name. A particular employee may be entered by one administrator as William, another as Bill, another as Will, and so on.
For Tasks
Due to limitations of previous version of the system. Since the 7.x series of TRACCESS only allowed a Task to have a single duration that applied to both the Knowledge and the Capability, some companies were forced to separate the task into two - one with the Knowledge component, one with the capability component.
Due to different people entering information. One person may create a Task named Forklift Training, another Comply with Forklift Training, and another Forklift 101. Each of these tasks may contain close, if not exactly duplicated resources.
Due to a misunderstanding of the programs functionality. Since Task names have always had to be unique, if an Administrator happened to receive the message that "This Task name is already in use" - rather than searching for the original task, the administrator may have changed the Task name slightly to force the system to allow this subsequent task to be added.
Regardless of the reason for Employee/ Task duplication, the desired end result is to merge the duplicates into a single object. Attempting to do this manually would inevitably lose some information. The incorporation of the merging function in the application is to attempt to keep as much information as possible on both original objects.
Since the goal of TRACCESS is to store information on an Employee's learning/ completion of tasks, the merging of employees and the merging of tasks are two separate operations that have several ties to each other.
The actual function is taking one object, merging it with another object, and the first object is deleted from the database. This could best be described using the Big Fish/ Little Fish analogy. It is exceedingly clear which object wins - and which object disappears. However, big fish task/ employee and little fish task/ employee didn't seem overly "professional" in software terms. Therefore, the little fish is known as the transient task or employee, and the big fish is known as the persistent task or employee. In the case of task and employee merging, you get to decide which will play the role of transient object, and which will play the role of persistent object.
There is a reason why the fish were drawn in this way (as opposed to the mirror image of this graphic). It is because in the Merge Employees/ Tasks dialog, the Employee/ Task that will be deleted (transient) is the one on the left. The Employee/ Task that will remain (persistent) is the one on the right.
|
|
|
|
