[OPEN-ILS-DEV] Apparent MARC import problem in 2.0.x

[Dan Wells]

Hello John,

You're example data got me thinking, as in EG the 901 tag is almost always the
last tag, while yours is not.  We are still working out the details, but it
seems in fact that a database trigger meant to strip out the 901 is in fact
stripping out all the <datafield> tags starting at 901.

So, while a fix is probably imminent, in the meantime you could either:

1) reorder your 901 fields to the bottom of your records
2) test out this attached version of the maintain_901 function

Please do report back if you get a chance to test this new version.

Thanks,
Dan


-- 
*********************************************************************************
Daniel Wells, Library Programmer Analyst dbw2 at calvin.edu
Hekman Library at Calvin College
616.526.7133


>>> On 2/17/2011 at 11:43 AM, John Craig
<jc-mailinglist at alphagconsulting.com>
wrote:

> 
> 
> I just did the simplest possible thing (called
> open-ils.cat.biblio.record.xml.update from srfsh using a record that
> includes a 907, 910, 945, etc field) and checked;  all of the 9xx
> tags came through just fine in the database.
> 
> Maybe if you included your program and a sample record we would be able
> to help you, but without that I have to assume the problem is in your
> custom program or in your data.
>   > I understand what you're saying, but including the program is both 
> impractical (no one is going to have the time to dissect it) and beside the

> point given these two facts:
> 1) I can see the data just fine in whatever tool I apply to the source 
> records. An example:
> 901             â–¼a4416208â–¼bUnknownâ–¼c428581â–²
> 906            
â–¼a7â–¼bcbcâ–¼corignewâ–¼d1â–¼eocipâ–¼f19â–¼gy-gencatlgâ–²
> 955             â–¼apc14 to la00 08-24-93; lg05 08-24-93; to lg03
08-24-93; 
> to sl 08-31-93; lg11 09-02-93; lb00 09-03-93; lb10 09-13-9
> 3
> ;aa03 9-13-93; CIP ver. pv04 11-01-94â–²
> 991             â–¼bc-GenCollâ–¼hDU740â–¼i.F64 1994â–¼tCopy
1â–¼wBOOKSâ–²
> 2) The tags show up in the osrfsys.log for the call to the method in 
> question--so my program is not stripping them out.
> 
> So, how it can be my program's problem is beyond me. What I really wanted to

> know was whether there was some setting or parameter of which I was unaware

> that would make the behavior I'm seeing expected. Nothing seems to come to 
> mind, so I'll just work with the situation as I find it.
> 
> Thanks for taking the time to run the srfsh test.
> 
> John
-------------- next part --------------
A non-text attachment was scrubbed...
Name: maintain_901_new_regex.sql
Type: application/octet-stream
Size: 2736 bytes
Desc: not available
Url : http://libmail.georgialibraries.org/pipermail/open-ils-dev/attachments/20110217/051bdef3/attachment.obj