<div dir="ltr">Dear All,<br><br>Springer has provided me with a .bin file. This file has marc21 data in it and when I stage it into Koha it works fine.<br><br>However I have to modify this marc file and add fields or edit fields using the [MarcEditor] tool.<br>
<br>Now the problem is, in order to read it correctly INSIDE the MARCEDITOR, i change the extension from .BIN to .MRC<br><br>This is ok up to the loading of the data into the MARC Editor.<br><br>Now, I added some new fields as well as I have edited some fields. Now the issue is here.<br>
<br>------------<br>After adding/editing fields in this file, I SAVE as MRC.<br><br>When I try to load this NEW marc file into KOHA using Staging, it does not go through and it says NaN error.<br><br>I am not sure what to do now.<br>
<br>I am using Koha 3.0.<br><br>Best Regards,<br><br><br><br><div class="gmail_quote">On Wed, Apr 21, 2010 at 8:37 AM, Susan Mustafa <span dir="ltr"><<a href="mailto:susan.mustafa@gmail.com">susan.mustafa@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;"><div dir="ltr">Dear Stacy, <br><br>At the moment, I did an import of the 14,000 records MARC file into Koha-Test.<br>
<br>I did a rebuild_zeba -r -a -b <-- I believe this clears all of the previous indexes and does indexing from 0.<br>
<br>Now, I know that there is a record called [Extreme Sports]. This record is from Springer, and it is shown under biblios table in MySQL Db after I finished importing the Marc file into Koha. However once rebuilding zebra, searching for this record returns 0.<br>
<br>Some springer records are searchable, but others Koha can't find. Does this mean that Zebra didn't index them [I see no errors when I do rebuild] OR does this mean that something else is wrong?<br><br><br>I did random checking of some records, obviously there is no way for me to check and see that all 14,000 RECORDs were indexed and Searchable? OR is there? You know this better than me.<br>
<br><br>Kindly bear with me on this. I might need your help since you did the Springer Import before.<br><br>Best Regards,<br><br><br>Now once I go into the MySQL DB, I see that the record for example [Extreme Sports] exists<br>
<br><div class="gmail_quote">On Tue, Mar 9, 2010 at 12:35 AM, Stacy Pober <span dir="ltr"><<a href="mailto:stacy.pober@manhattan.edu" target="_blank">stacy.pober@manhattan.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
I loaded about 17,000 Springer ebooks into our catalog. I did not<br>
directly upload them into Koha, though. First, I edited them in the<br>
free MarcEdit program to add some fields.<br>
<br>
We use EZproxy to allow our users to access IP-restricted resources<br>
from off-campus. If you use something similar, you would use the<br>
Edit Subfield Data function to alter the 856$u data. You would<br>
replace "http: with something like<br>
"http:<a href="http://ezproxy.yourlibrary.edu:2048/login?url=http" target="_blank">ezproxy.yourlibrary.edu:2048/login?url=http</a>:"<br>
<br>
Additionally, the Springer ebook MARC records do not come with any<br>
custom link text. We added custom link text by adding an 856$y<br>
field. with the text "Available for our library via Springer eBooks.<br>
Click here for access". The custom link text is often provided in an<br>
856$w field rather than the $y field, and the $w and $y but they seem<br>
to display exactly the same in our catalog, so if you get other<br>
vendor-supplied records with 845$w fields, you don't need to change<br>
them unless you want to customize the link text.<br>
<br>
We also add a 952 field to specify the branchcode, ITYPE, shelving<br>
location and CCODE:<br>
\\$aMAN$bMAN$cEBOOKS$oELECTRONIC BOOKS$yEBOOKS$8EBOOKS<br>
<br>
The branch code needed to be added because without it, each ebook<br>
appeared in Koha with messages about availability that we did not want<br>
to see. Adding the ITYPE allowed us to add a "View this eBook" link<br>
to each summary record which is a nice convenience for end-users.<br>
<br>
We also add a 500$a field which lists the ebook service name (Springer<br>
eBooks) because that's the standard way we've been listing all other<br>
ebook packages (not all of the vendors have the package name anywhere<br>
in the record) and a 099$a field for Local Call Number of ELECTRONIC<br>
BOOKS because that's the way our other ebooks have always been listed.<br>
<br>
You may not need or want this level of customization, but it's nice to<br>
know it's available.<br>
<br>
When I first tried to upload the Springer records, I could not<br>
upload them in one step. Our catalog is hosted by LibLime and at the<br>
time I processed these records (a couple of months ago), the server<br>
response time was very slow and it would time out for large uploads.<br>
This was the only batch of MARC records I had that was quite so large,<br>
and I had to split the 17,000 records into batches of about 1500<br>
records. I don't know if there is any effective limit on file size<br>
for uploads in the official version of Koha.<br>
<br>
The processing of the initial file of the large Springer ebook record<br>
set was tedious but routine. However, Springer issues updated record<br>
sets for books they add to your subscription each month, and I am<br>
currently trying to work through some problems in the December update<br>
file. The monthly updates come in separate files for each publication<br>
year. We get five years of books, and rather than having to process<br>
them separately, I used MarcJoin in MarcEdit to concatenate them into<br>
one large file. This did not work, because it turned out there were<br>
some invalid characters in two of the records that caused errors in<br>
the joined file. I'm still working through that. The individual<br>
files validate correctly using the validator in MarcEdit, so I need<br>
to find a 'pickier' MARC validator to find the invalid characters.<br>
<br>
One more thing about ebook MARC records generally: I find that the<br>
quality of publisher-supplied MARC records is very variable. One<br>
problem we ran into with the MARC record sets for netLibrary and a<br>
couple of other vendors is that some of the records included multiple<br>
$856$u fields with URL's leading to other subscription-based online<br>
services to which we have no access. I had to find those bad URLs<br>
and strip them out of our records, and that was a little tedious.<br>
<font color="#888888">--<br>
Stacy Pober<br>
Information Alchemist<br>
Riverdale, NY 10471<br>
<a href="mailto:stacy.pober@manhattan.edu" target="_blank">stacy.pober@manhattan.edu</a><br>
</font></blockquote></div><br></div>
</blockquote></div><br></div>