We cannot update our archive

I am helping a watermill charity to archive documents onto CollectiveAccess. The archive was set up a few years ago and the database now contains approximately 1000 records. There are a further 400 to be added. (Note the charity has little money & selected a free option, even though CollectiveAccess is probably too large & comprehensive for their needs).

However, the volunteers in the Archive team who did the initial work are no longer available (or contactable) and the new team are struggling to process any further records. I should add that nobody at the watermill has any knowledge of how CollectiveAccess operates etc.

What the Archive team want is to post the minimum amount of information to support an archived document. 

For example – Invoice dated 1900 – would accompany a scanned copy of the invoice.

Each attempt is met with a whole bunch of errors. Today I accessed a record and I could see how much (or little) information was there. I then attempted to save it without any changes & got the following

There are errors preventing ALL information from being saved. Correct the problems and click "save" again.

  • '1' for extent is not numeric
  • '1' for access is not numeric
  • '434' for type id is not numeric
  • Type must be specified

I then tried to enter a completely new record using fields copied from the saved record. Again I got a errors very similar to the above.

Can anyone suggest any steps we could take to clear the logjam?

Many thanks


  • When creating the record did you select if the record was for a document/text/etc? Are the new volunteers entering the information in a similar manner to the ones already entered? My first thought is that one possibility that the error is caused by the system expecting information entered in a specific fashion to keep the records consistent. However, the "type must be specified" error suggests that a rule set up by the system itself.

    I would also check if the system has enough storage. Is the system on a local machine or on a server?

    As for CollectiveAccess being too complex, you can turn off several features that the organization does not use.

  • sjenson, Thank you for your very prompt reply.

    I think you may be right about the tailored version for the watermill.

    I have compared our version with the version used in the YouTube demo & there are significant differences.

    When creating a new object the demo system offers New / Object & then a choice of Archival. Artifact or Hybrid.

    In our system it is New / Object / Document, Photograph or Other. Also there are no "i" next to fields for information on how to complete the field.

    The version being used is dated 2017. Could we out of step somehow?

    Thanks again

  • CollectiveAccess has different installation options for different types of museums/archives/etc. so the changes might be due to what the original volunteers used as the starting profile. The system should still work even though CollectiveAccess has several releases and patches since then.

    Any chance that the original volunteers left documentation to explain the metadata format? I know one of the volunteers here has a complained that he has put together a book on how to use the volunteer database, but no one reads it.

    While I am not one of the devs, and if you wanted to update the system to see if it: the way I would go about updating the program from 2017:

    1. Backup up the MariaDB/MySQL database and download it from the server
    2. Download the media directory
    3. Under Manage -> Administrative -> Export Configuration and download it locally
    4. Duplicate the MariaDB/MySQL database on the server
    5. Update the server (Apache/nginx, MariaDB/MySQL, PHP7.4*)
    6. Clone a new copy of Providence into the server but do not install (for the sake of this example I am going to call the folder "providence2" and assume the original folder is just called "providence")
    7. Edit the setup.php file to match the old system
    8. Test to see if it works (note none of the media will appear at this point as the media is in a different folder)
    9. The system will see the old installation options apply the migrations from the earlier (hence why you did not want to run a providence2/install.php)
    10. Delete providence2/media
    11. move the Media folder to the new installation folder
    12. rename providence to something like providence-backup
    13. rename providence2 to providence

    *Last I checked, which to be fair, was about a year ago, the devs were still updating the system to work with PHP 8

  • sjenson. Again, many thanks for your help.

  • Out of curiosity, were you able to get the database working again?

Sign In or Register to comment.