[OPEN-ILS-GENERAL] Marc Export Script Error

Jesse McCarty jessem at burlingtonwa.gov
Tue Jul 28 14:27:11 EDT 2015


Thanks for the information Ben. We are running Evergreen 2.7.3 in production & our test server. Our newly built server is running Evergreen 2.8.1 (plan to upgrade to 2.8.3 prior to deployment). The script ran, but produced no final .gz file (just the errors mentioned originally). Would our library staff be able to take the ID's and locate the record in question? I couldn't figure out how to take the ID given and find the record to see what was going on (tried searching in the staff client, but nothing came up). Of course, I wouldn't know what to look for once I found the MARC record so hopefully the library staff would recognize a bad MARC record...

Thanks again.

Jesse McCarty
City of Burlington
IT Technical Assistant


-----Original Message-----
From: Open-ils-general [mailto:open-ils-general-bounces at list.georgialibraries.org] On Behalf Of Ben Shum
Sent: Tuesday, July 28, 2015 10:50 AM
To: Evergreen Discussion Group
Subject: Re: [OPEN-ILS-GENERAL] Marc Export Script Error

For more details and history.... in IRC logs -
http://irc.evergreen-ils.org/evergreen/2014-07-30#i_114153 -- csharp encountered malformed MARC in his tests with marc_export post Evergreen 2.6 era.  Dyrcona created a patch and this was applied with Launchpad -- https://bugs.launchpad.net/evergreen/+bug/1350345 -- to avoid having marc_export die from bad records.  From the LP, the maintenance releases that contained those fixes were 2.7.0 and 2.6.4.

So yeah, my guess is that there's something wrong with those MARC records on your system Jesse.  Since you have the IDs from the export attempt, you can try to determine what is in those records that cause them to fail to export cleanly.

-- Ben

On Tue, Jul 28, 2015 at 1:34 PM, Ben Shum <bshum at biblio.org> wrote:
> Hi Jesse,
>
> Some questions for you... what version of Evergreen are you using with 
> that PostgreSQL 9.3 system?
>
> That error you're seeing from the upgrade log sounds like maybe you 
> might not have your search_path set appropriately after the database 
> was copied over.  For example:  "After restoring a database, make sure 
> to reset the search_path accordingly with something like: alter 
> database unpredicable_haxxors_go_away set search_path = evergreen, 
> public, pg_catalog;"
>
> As for that other error, Substr outside of string at 
> /usr/share/perl5/MARC/Record.pm line 573 ; my guess is that you have 
> some bad MARC records in your database.  This is likely unrelated to 
> your change in PostgreSQL, or maybe the version of MARC::Record that 
> you're now using is less tolerant?  Or maybe you were using the older 
> marc_export script before it was changed around 2.6 or so and it 
> somehow tolerated the bad MARC better.
>
> In any case, I would check those bibs out on your system to determine 
> if there's any red flags in the way the MARC was created.  Maybe 
> there's something that doesn't conform to the "standard" and that's 
> making things unhappy.
>
> -- Ben
>
> On Tue, Jul 28, 2015 at 12:30 PM, Jesse McCarty <jessem at burlingtonwa.gov> wrote:
>> Hi Everyone,
>>
>>
>>
>> I am working on a new Evergreen Server to deploy in the fall (Ubuntu 
>> 14.04, Postgres 9.3 – Current system is Ubuntu 12.04, Postgres 9.2) 
>> and am running into an error with the marc_extract script. The script 
>> works with no issue on the production system running Postgres 9.2, 
>> but after I import the current production data into a test server 
>> (identical to the current production server, with older DB data) and 
>> upgrade Postgres to 9.3 it stops working with the following error:
>>
>>
>>
>> Error in bibliographic record 168171
>>
>> Substr outside of string at /usr/share/perl5/MARC/Record.pm line 573
>>
>>
>>
>> There are two other bibliographic records that have the error as well
>> (168498 & 172482).
>>
>>
>>
>> The new database seems to be working otherwise (attached is a screen 
>> shot of the output of the pg_upgradecluster results) even though the 
>> upgrade showed some errors.
>>
>>
>>
>> Any help is greatly appreciated. Thanks!
>>
>>
>>
>> Jesse McCarty
>>
>> City of Burlington
>>
>> IT Technical Assistant
>>
>>
>
>
>
> --
> Benjamin Shum
> Evergreen Systems Manager
> Bibliomation, Inc.
> 24 Wooster Ave.
> Waterbury, CT 06708
> 203-577-4070, ext. 113



--
Benjamin Shum
Evergreen Systems Manager
Bibliomation, Inc.
24 Wooster Ave.
Waterbury, CT 06708
203-577-4070, ext. 113


More information about the Open-ils-general mailing list