Hello Jesse, For your first issue, it appears you have some kind of encoding problem in some of records. This is very common for any record with foreign characters. Without getting into too much detail, MARC records are generally supposed to use UTF8 encoding (a modern, universal encoding) or MARC8 encoding (an older, library-centric standard). Records will commonly say they use one encoding but have characters from the other, or use characters from an entirely different, unsupported encoding (e.g. Latin 1). I would recommend you try to sort these out eventually, but I don't think you are doing any additional harm here.
For the 901s update, this update is kinda brute-force, so there is a chance you will run into table lock problems if anyone else tries to update the biblio.record_entry table while this is running. The biblio.record_entry table doesn't get updated during normal OPAC and circ operations, so if you can avoid saving records, you should be able to run it while live. A safer option (which we typically take) in situations like this is to actually generate a file where every update is a separate command (UPDATE biblio.record_entry SET marc = marc where id = 123; UPDATE biblio.record_entry SET marc = marc where id = 124; ... etc.). Such a setup lets it plod along without holding onto multiple rows as the work is done. Let me know if you need more guidance in creating such a file. Also, that upgrade step comes from this feature addition: https://bugs.launchpad.net/evergreen/+bug/1307553 . Unless you actively plan to take advantage of this new source subfield $s, you can delay this entire command until a more convenient time. It won't affect any normal operations to not have that subfield populated. Sincerely, Dan On Wed, Apr 19, 2017 at 4:22 PM, Jesse McCarty <jes...@burlingtonwa.gov> wrote: > Hello Everyone, > > > > We are preparing for our spring upgrade to Evergreen, moving from 2.10.3 > to 2.11.3 and ran into one little bump. As part of the DB upgrade, there is > an update setting the 901$s for bib records. First question, as seen in the > attached screen shot, this threw a bunch of ‘no mapping found for….’ > Errors. Can this be safely ignored and proceed with running the system > after upgrading with no issues (we haven’t seen any issue in our testing)? > > > > The second, this update seem to take longer than 24 hours. With that in > mind would we be able to process the entire upgrade, then use Evergreen in > daily production while this DB update finishes in the background? Or does > this need to be 100% complete before allowing library’s connection to the > system? > > > > Thanks in advance, > > > > Jesse McCarty > > City of Burlington > > IT Technical Assistant > > >