From the stdlog; factory.c 7262 Dangling reference to persid rc:
How can I resolve this error?
A "dangling reference" occurs when a database record in a table has a reference relationship to another record in another table, however that record which its referencing was removed. For example, lets say you have a request in the call_req table that has an assignee on it. That assignee field in the request record is stored in the form of a UUID, which relates to the UUID of that assignee's contact record. Now lets say you go into the database and delete that contact record for that assignee. That request record now has a UUID for the assignee, for which that UUID no longer exists in the contact table. Thus that ticket has a "dangling reference" to a record in the contact table that does not exist. Dangling references are considered a form of "data corruption" in a way because records are referencing other records that dont exist, so its a corrupt relationship. So the truth is that the only way dangling references will occur is if data is manually removed from the database. This is the reason why service desk never deletes data, but only inactivates records, this way if something is referencing those records, it doesnt create dangling references.
Now, for your specific error, I am not sure what table its referencing - can you provide us the complete log message(s) you are seeing in the logs? This way we can give you an idea of what to look for.
Hope this helps a bit,
Further more, the error message states "Dangling reference to persid rc:" So this implies the culprit missing record(s) was in the rootcause table.
It is obviously a root cause issue but I can’t believe we have deleted a record in the database. I have been wrong before, however.
We do require a root cause on a Closed status, so even though these logs entries are sequential, not sure they are related.
I did check the Call_Request table for the cr: indicated in the log and the root_cause field is null.
What I did find out, this was from a “Quick Close” template and the ticket was closed at the time the log entry was created.
We moved from 12.6 to 14.1 cum3 on 10/3/1016 and I realize the logging is different, I never saw this in 12.6…
I assume I can ignore this (or fix the template.)
10/26 08:46:49.50 EHS-AP-CA-W1 domsrvr 9044 ERROR factory.c 7262 Dangling reference to persid rc:
10/26 08:46:50.94 EHS-AP-CA-W1 domsrvr 9044 SIGNIFICANT dob.c 4185 Required dependent attribute Root Cause is missing from object Request [cr:13854834] ->CL
10/26 08:46:51.52 EHS-AP-CA-W1 domsrvr 9044 SIGNIFICANT dob.c 4185 Required dependent attribute Root Cause is missing from object Request [cr:13854834] CL->CL
10/26 08:47:14.78 EHS-AP-CA-W1 domsrvr 9044 ERROR factory.c 7262 Dangling reference to persid rc:
So then in this case, it can be ignored. If your quick close template does not have a root cause on it, but its allowing it to close it anyway, then that would cause this to occur. I would say to fix the template to be honest - just populate it with some type of "quick-close-root-cause" value of some sort.
As a follow-up, it appears that if you use a "Quick Close" incident template created from the Quick Profile tab, the root cause is not populated on the ticket even though it is in the template. This may be a bug?
It could be - can you provide us a full set of steps to replicate the scenario here and I can give that a quick run to test it out?
Let me know,
To recreate this: in CA SDM 14.1 cum3
I created a new quick close template,(quick, no review) including a root cause (incident and request)In the Quick Profile tab, I selected a contactAdded a note in the scratchpad then selected my new test quick templateClicked the Quick Close button.I get the message that the quick close incident was created
root cause was not included in the quick close tickets
This does not happen if you do a quick incident/request, only quick close incident/request
Just to be fair, this also happened in 12.6 so it's not new to 14.1
Retrieving data ...