Dan, Any assistance with creating a file that will break up the update task would be greatly appreciated. We ended up deciding to hold off on upgrading until 3.0 was released and we have a running test server with semi current data in it. But, after doing all the re-ingests and other associated DB upgrades throughout the various DB scripts, running the update biblio.record command took something like 4 days. I’m not sure how the 901 field is used within our library, but I would like to ensure the upgrade is done completely so there are no surprises as well as get everything ironed out in the testing environment so I know exactly what to expect when we upgrade the production system to the 3.0 series.
Thank you again, Jesse McCarty City of Burlington Information Systems Technician From: Open-ils-general [mailto:[email protected]] On Behalf Of Daniel Wells Sent: Wednesday, April 19, 2017 7:38 PM To: Evergreen Discussion Group Subject: Re: [OPEN-ILS-GENERAL] Upgrading from 2.10 to 2.11 error questions 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 <[email protected]<mailto:[email protected]>> 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
