[Archivesspace_Users_Group] date_type accession record errors

[Mark Cooper]

Hi Steve,

I think you're essentially correct here.
Direct DB updates are generally frowned upon but are the easiest way out in this case.
I'm going completely off memory so backup and try things carefully as I may not be 100% accurate with the SQL:

Get the ids for the controlled values from the `enumeration_value` table.

===
SELECT ev.id, ev.value FROM enumeration_value ev JOIN enumeration e ON e.id = ev.enumeration_id WHERE e.name = 'date_type';
===

Update the `date` table `date_type_id` replacing the capitalized value id with the lower case value id.
Simplest update would be something like:

===
UPDATE `date` SET date_type_id = $lower_case_value_id WHERE date_type_id = $capitalized_value_id;
===

With no relationships to the capitalized value it should be possible to delete it:

===
DELETE FROM `enumeration_value` WHERE id = $capitalized_value_id;
===

And I'm not completely sure but I think newer versions of ASpace prevent this from occurring, but I could be wrong on that.

Best,
Mark
LYRASIS

________________________________
From: archivesspace_users_group-bounces at lyralists.lyrasis.org <archivesspace_users_group-bounces at lyralists.lyrasis.org> on behalf of Steven Giessler <Steve.Giessler at mail.wvu.edu>
Sent: Friday, August 12, 2022 2:30 PM
To: archivesspace_users_group at lyralists.lyrasis.org <archivesspace_users_group at lyralists.lyrasis.org>
Subject: [Archivesspace_Users_Group] date_type accession record errors


Dear ArchivesSpace Users Group,



Here at West Virginia University, we have a problem where a batch upload of accession records are resulting in new errors appearing in the logs with:



F, [2022-08-11T20:14:53.833183 #10996] FATAL -- :
F, [2022-08-11T20:14:53.833850 #10996] FATAL -- : ActionView::Template::Error (No such template: "date_type_Single"):
F, [2022-08-11T20:14:53.834690 #10996] FATAL -- : 45: <% end %>



When you try to Edit each record, and you cannot edit but simply get the dreaded: “We're sorry, but something went wrong.”



Based on the error message in the logs we see when we click “Edit,” we believe that the Value field single was accidentally capitalized during the batch uploads in .csv files used for the uploads. So, it should have been lower case “single” instead of “Single” (we surmise).  The first attached screenshot (I hope screenshots are allowed to be included with postings here) shows that we now have a couple of extra value columns now for date_type, with records separated into two groups for each of the erroneous Value fields (Single, and Inclusive which you can see are the last two rows under Controlled Value List: Date Type (date_type). The 2nd attached screenshot shows a sample of the column in the .csv used for the batch upload with the capitalized date_1_type fields.



We are thinking to fix this, we probably need to merge “Single” items with “single” and “Inclusive” items with “inclusive” with lower case Values being the ones they get merged into and then deleting the corresponding capitalized Value instances.



Does this make sense? If so, how can we clean this up? I am guessing we may need to edit the MySQL database directly? Or is there a better way through the GUI? With many other Controlled Value Lists there are three options (Suppress/Merge/Delete) in the GUI for each Value, but not so for date_type which only has “Suppress” as an option. If we could Merge and then Delete we could probably clean this up in the GUI, but that doesn’t appear to be an option for us.



We are presently running ArchivesSpace version 2.8.0 on Red Hat Enterprise Linux 7.



Thank you in advance for any suggestions,



Steve Giessler

Professional Technologist

WVU Libraries
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lyralists.lyrasis.org/pipermail/archivesspace_users_group/attachments/20220813/40c18730/attachment.html>