Why am I receiving "Cannot insert duplicate key row..." error?
This error can be encountered when adding or updating a timesheet row to have the same identifying values as another row within one edit session (without saving in between). The ‘new’ row on the timesheet is compared to an ‘old’ existing row on the database and gets this error.
For example: You have a row on your timesheet charging to Project A, and you modify its value to Project B. Then - without hitting save - you either add a new row or change another row to have a value of Project A. When you save, the system may attempt to process the second record before the first record has been updated. This is why the system may think you have two Project A entries on your timesheet. Note that "Project A" refers to the entire set of key values for a timesheet row, which may include more fields such as project, task, pay code, project type, labor category, location, etc.
Encountering this message does not impact the integrity of the data saved in your system, but simply prevents the saving of that set of updates on the screen.
In order to avoid this situation, save the first update to the line with Project B, then make the update to the line with Project A and save that change. This sequence of events should not trigger the Unique Constraint error.
If the Unique Constraint error is triggered, there are a few options to resolve:
- Try to delete one of the rows and save.
- Restore the two rows to their original value and save.
- Log out, close the browser, then log in again to edit the timesheet; it should retain its original entries because the duplicates were not saved.
Other possible causes of this error include:
- Swapping project or task entries on the timesheet.
- Modifying an assignment, which causes timesheet changes during re-rating (the re-rate can leave some time outside of an assignment, and thus can cause it to default to a new value for labor category).
- Modifying the list of master or project labor categories, such that the update results in a new first entry in the list.
- The first labor category in the list is sometimes chosen in situations where a labor category is required but none is provided on an assignment and there is no default labor category (or the default is not on the list of valid project labor categories).
- Modifying the list may change the labor category to be the same as another row on the timesheet, thus causing the duplicate. The default Labor Category changes + there is time using the current default value + the new default Labor Category is already on the timesheet = duplicate row error.
- Changing the Admin > Properties setting to hide labor category on the timesheet, after two rows with different labor categories have already been saved.
- In these cases, the next time the timesheet is saved (and the system attempts to re-rate the entries on the timesheet) the labor category defaulting logic kicks in and both rows may now pick up the current labor category (from the assignment or default labor category).
- The key here is that when the labor category is shown on the timesheet, the system requires that one be selected instead of attempting to default a value. However, when labor category is hidden on the timesheet, the system will attempt to derive a default value and then attempt to stamp multiple rows with the same labor category.
- Updating time via a time import or an assignment import.
For example, situations in which pre-populated holidays are set up and then timesheets with holiday rows in the file are imported.
SQL Exception – Cannot insert duplicate key row in object 'person_time_data' with unique index 'idx_person_time_data1'.
There was a SQLException while processing /unanet/action/projects/assignment/save.
SQLException caught in com.unanet.servlet.ActionServlet.