[OPEN-ILS-GENERAL] EG 2.0: problem Marc2bre - Global Flags "Maintain 001-003-035 according MARC" and "TCN=Internal ID"

[Repke de Vries]

Apologies Dan for the long gap discussing this - and thanks for your fix (part of the 2.0.2 release) that makes the Global Flag "Cat: Use internal ID for TCN value"  when set to TRUE, have the same effect for command line importing bib records as it already had  for importing through the GUI. 

However:  also the other Global Flag "Maintain 001-003-035 according MARC"  when set to TRUE,  behaves differently when importing bib records from the command line then through the GUI:

- through the GUI  the Control Number in the imported bib record's 001 field gets pushed to the 035 as expected and the 001 receives the Evergreen Internal Record ID etc.; and because of the Global Flag "Cat: Use Internal ID for TCN Value" the TCN follows this Internal Record ID 
- importing from the command line the Global Flag setting is ignored however and the Control Number in the imported bib record's 001 field becomes the new Evergreen Record ID;  the TCN also ignores it's Global Flag Setting -  this latter behaviour has been fixed now (as I understand it)

Question though:  does your fix also remedy the other expected behaviour "Maintain 001-003-035 according MARC" when importing bib records from the command line?

And if not: what can we do about it?

A further comment on your  
> 
> This is extremely useful  ["setting the record ID to whatever number is in 001"] if you have separate records for holdings, etc, that point to an existing record ID that you need to sync them up with
> during your migration.

True that with Global Flag "Maintain 001-003-035 according MARC"  set to TRUE, life gets a bit more complicated linking MARC Holding and Bib Record but still doable: IISH (Chris Roosendaal) discussed this over IRC a while back with this outcome while using a "staging table" approach [quote from the IISH documentation]: 
"..In our Evergreen 2.0 database this JOIN did not work, because the bibkeys were replaced by an internal auto-increment key when the bibliographic records were inserted. Fortunately there is a mapping between the original bibkeys and the new keys in the metabib.real_full_rec table, and therefore an extra JOIN is needed.
.."  after which bib and holding record can be successfully linked. 
 
And one odd observation:  doing a command line import for authority records, the command line behaviour *is* the same as thorugh the GUI.

Repke de Vries, IISH


Op 17 feb 2011, om 00:36 heeft Dan Scott het volgende geschreven:

> On Fri, Feb 11, 2011 at 04:36:04PM +0100, Repke de Vries wrote:
>> 
>> Command-line importing with marc2bre + pg_loader [1] in EG RC2
>> Virtual Image, the import went fine but the Global Flags settings
>> "Maintain 001-003-035 according MARC" = TRUE and "Cat: Use Internal
>> ID for TCN Value" = TRUE are being ignored.
>> 
>> In other words:  I am getting a Record ID and TCN that are
>> derivatives of the control number in the imported 001 field: wrong.
> 
> Well, the results for the record ID are what I would expect and want. By
> saying "give me the value of 001 for my record IDs" in marc2bre.pl with
> --idfield 001, that sets the record ID to whatever number is in 001.
> This is extremely useful if you have separate records for holdings, etc,
> that point to an existing record ID that you need to sync them up with
> during your migration.
> 
> The TCN though... I took a look at where cat.bib.use_id_for_tcn actually
> gets used, and it's only in the Perl O:A:Cat::BibCommon module. Which
> doesn't get called by any of the in-database ingest code that is used in
> 2.0, it would only be called when you're working with the GUI.
> 
> A simple/simplistic way to fix this in the short term would be to run
> (after importing all of your bib records):
> 
> UPDATE biblio.record_entry SET tcn_value = id;
> 
> I would consider this a bug, though, as the expectation when you set
> "Cat: Use internal ID for TCN value" to TRUE is for that to be the case
> no matter how you get the records into the system. In which case, a
> minor tweak to the maintain_901 or maintain_control_number triggers
> should suffice (maintain_901 because it occurs before
> maintain_control_number, although perhaps that order should be
> reversed anyway to ensure that maintain_901 inserts the correct values
> in the correct spots...)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20110304/7bc76a3e/attachment.htm