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.


On Wed, Apr 19, 2017 at 4:22 PM, Jesse McCarty <jes...@burlingtonwa.gov>

> 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

Reply via email to