If you switched to a new DB, but did not delete the solr indexes in data/solr_index/ or deleted the files in data/indexer_state/ and data/indexer_pui_state/ to trigger a reindex then the data in DB and SOLR will be out of sync.
If this is the case, the PUI, which pulls data from SOLR rather than the DB will be incorrect. The staff interface pulls data from both sources, depending on the action, and so will sometimes show you something in the index that isn’t there when you attempt to edit it. The backend API calls usually pull from the DB for non search functions. Ask them to delete the files in archivesspace/indexer*state/* and wait for reindex to complete. — Steve Majewski > On Jul 14, 2021, at 4:02 PM, Merryman, Ann <merry...@uscupstate.edu> wrote: > > Good afternoon hive mind…long time lurker, first time writer. J I’m going > to try to make this question concise: > > · I have just been upgraded to v2.8.1 (from v1.3.0…don’t judge! Lol) > on a locally-hosted instance of AS, managed by my university’s IT department. > · When my instance was upgraded, I got the following warning message: > Database Warning: You are currently using the embedded database (Apache > Derby). The embedded database is for testing/demo purposes only. You should > use MySQL for any data intended for production, including data in a test > instance that you intend to move over to a production instance. > > · The vendor let us know that there were not any upgrade paths from > the demo database to MySQL, and the information would have to be re-entered > (this is fine, as I had backed up everything and could re-enter) > · Once IT built the MySQL database, however, all the accession and > resource records actually showed up. ??? > > The problem is, while I can *see* the records on the back end, I can’t edit > or delete them. However, they are visible and searchable on the PUI. I’ve > attached a few images for reference. > > I’m trying to determine what the best course of action might be before I go > back to my IT department, as I’m going to have to explain what the issue is > to them as best I can (they’re not really familiar with AS or archival > processes, unfortunately). I’m not clear on why the data pulled over if > there wasn’t a path, and I’m not tech savvy enough to guess at what my IT > department did. I could also email AS tech support, but I thought I’d start > here to see if anyone has seen this or has something to try first. > > Any thoughts or suggestions from the group would be greatly appreciated, or > even just sympathetic noises. J > > Thanks so much, > > Ann > > “For the things we have to learn before we can do them, we learn by doing > them.” ~ Aristotle > > Ann E. Merryman, MLIS > Associate Librarian > Coordinator of Archives and Special Collections > <image002.png> > USC Upstate, Library 263 > 800 University Way > Spartanburg, SC 29303 > Office: 864-503-5275 > merry...@uscupstate.edu <mailto:merry...@uscupstate.edu> > > <ASpace resources image 1.JPG><ASpace resources image 2.JPG><ASpace PUI image > 1.JPG><ASpace PUI image 2.JPG>_______________________________________________ > Archivesspace_Users_Group mailing list > Archivesspace_Users_Group@lyralists.lyrasis.org > <mailto:Archivesspace_Users_Group@lyralists.lyrasis.org> > http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group > <http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group>
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Archivesspace_Users_Group mailing list Archivesspace_Users_Group@lyralists.lyrasis.org http://lyralists.lyrasis.org/mailman/listinfo/archivesspace_users_group
