[OPEN-ILS-GENERAL] Marc field change script

2020-04-06 Thread Glen Modell
Hello, I would like to know if anyone has a script which changes or eliminates a given MARC subfield for a given list of bibliographic records. In particular, we have about 10,000 records with contents in the 100-e subfield which we would like to eliminate. In those cases, the 100-a ends in a c

Re: [OPEN-ILS-GENERAL] Marc field change script

2020-04-06 Thread Linda Jansova
Hi Glen, In some cases MarcEdit can be a good solution: https://marcedit.reeset.net/ (but it involves exporting and importing the records in question - if the records are already loaded in Evergreen; if not, then MarcEdit can be the best option). Linda On 4/6/20 6:20 PM, Glen Modell wrote:

Re: [OPEN-ILS-GENERAL] Marc field change script

2020-04-07 Thread Rogan Hamby
Hi Glen, If you have someone on staff comfortable with MARC::Record this is a simple thing to do with PLPERL as a function. In fact I'd say this is a good really simple one for someone to cut their teeth on if they were learning and the kind of thing I was going to do in the preconference. Depen

Re: [OPEN-ILS-GENERAL] Marc field change script

2020-04-07 Thread Jason Stephenson
Glen & Rogan, I prefer to do these things outside of the database, i.e. pull the record out with DBI, modify it, and then update it with DBI. I'm not a fan of writing database functions for something that I'll use only once or twice. I have some utility scripts that I've used and shared with the

Re: [OPEN-ILS-GENERAL] Marc field change script

2020-04-07 Thread Rogan Hamby
To me, and this is personal preference I think, I don't see a big difference between writing something once outside the db versus in it. Both approaches are fine in my mind. It does make me think of a point I didn't mention though, which is I wouldn't store a function in any existing Evergreen sch

Re: [OPEN-ILS-GENERAL] Marc field change script

2020-04-07 Thread Jason Stephenson
It is personal preference. I agree wholeheartedly on creating your own, custom schema for nonstandard things. We've got a schema called cwmars for custom functions, views, and tables that we use in some local processes. I've also added a schema called backstage to use exclusively with our quarter