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...)
