Hi Janet, Yes, the loader is slow and not very robust in terms of how big a bib file you can load through Vandelay. I tried a big file yesterday, and it choked at the 1000 record mark. When we got things started again, the queue was empty.
The OCLC records come out of Connexion with the OCLC number in tag 001. To keep it there, I changed the flag found in Admin/Server Administration/Global Flags that says " Cat: Maintain 001/003/035 according to the MARC specification." We set that to False, so the 001 doesn't get changed. We also set the flag found in the same place "Cat: Use Internal ID for TCN Value" to False, to keep the record ID from becoming the TCN. My match points for my straight OCLC record load is on the record attributed "oclcnumber" (thanks to Kathy Lussier for the assistance in getting that set up), and tag 019, though I don't hold much hope for that. My intent is to match an existing OCLC number to an entry in tag 019 subfield a when our OCLC number has been made obsolete, but since the number in tag 001 has a prefix and the number in the 019 does not, I don't expect success in matching the numeric string alone. I've also created a match set for upgrading the brief vendor acq records, based on 020 or 024 or 028 to catch the nonbook bibs. That seems to be working pretty well. Whatever line of code that allows an import via Z39.50 to change the TCN, I wish that would be added to the Vandelay code. I run a script to find vendor-created brief acq records based on the TCN not beginning with "oc%", and if a Vandelay load to upgrade those acq records doesn't replace the TCNs with OCLC numbers, I'm going to keep seeing the same bibs everything I run my script, even after they've been upgraded. Two other things on my wishlist: -- I'd like to be able to change the bib source when we overlay a bib record. I created a bib source of "acq" for brief records, and I'd like the loader to change it to "oclc" when the record is overlaid. --When a record is overlaid through Vandelay, I'd like to see the "Last Edited On" date/timestamp be updated to reflect the latest load. The Z39.50 overlay changes that date/time. Mary -----Original Message----- From: Janet Schrader [mailto:[email protected]] Sent: Tuesday, February 07, 2012 6:12 PM To: '[email protected]'; 'Evergreen Discussion Group' Subject: RE: [OPEN-ILS-GENERAL] Vandelay 2.2. question Hi Mary, I've been testing Vandelay and find it very slow. It takes 5-10 minutes to process files of 6 or 12 records and 2-5 minutes to load the records. My attempt to load a file of 500 records just died in the processing phase. I am matching on 035, 020, and 010. It turns out the file of 500 records had no match-points for records in our database. How does this compare with what you are seeing? Also, how do you get the OCLC numbers into the 001 field? Did you do this during migration. I load 1,000s of EBrary records where the only numerical match-point is the EBrary control number in the 001 field and I'd prefer to keep it that way. Currently our EG 001 field is the TCN. Thanks, Janet Janet Schrader C/W MARS Inc. 67 Millbrook Street, Suite 201 Worcester, MA 01606 tel: 508-755-3323 ext. 25 fax: 508-757-7801 [email protected] -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Mary Llewellyn Sent: Monday, February 06, 2012 5:20 PM To: 'Kathy Lussier'; 'Evergreen Discussion Group' Subject: Re: [OPEN-ILS-GENERAL] Vandelay 2.2. question Hi Kathy, Just tried my overlay set-up and it worked beautifully. Matches and overlays abound. Thanks so much for your help. Except....when I do an overlay with Z39.50, I can get the TCN to change to the OCLC number. I didn't get that result with my Vandelay overlays. I want to, very much. Is there a setting I missed that would make that happen? Or is it a programming oversight, that the two types of import/overlay don't achieve the same results? Again, thanks for any insights. Mary -----Original Message----- From: Kathy Lussier [mailto:[email protected]] Sent: Monday, February 06, 2012 4:02 PM To: [email protected]; 'Evergreen Discussion Group' Subject: RE: [OPEN-ILS-GENERAL] Vandelay 2.2. question Hi Mary, I can answer your question about the 001 field. You need to make the 001 field a record attribute to match on it. You can do so by going to Server Admin < MARC record attributes. I've attached a screenshot of the 001 record attribute we set up when testing. Once you set up the record attribute, you can build a match set based on the record attribute (you may need to first reboot the client). Instead of selecting MARC tag and subfield when building your match set, click the "record attribute" button. The new attribute you just created should be available in the list. I hope this helps! Kathy ------------------------------------------------------------- Kathy Lussier Project Coordinator Massachusetts Library Network Cooperative (508) 756-0172 (508) 755-3721 (fax) [email protected] IM: kmlussier (AOL & Yahoo) Twitter: http://www.twitter.com/kmlussier >>-----Original Message----- >>From: [email protected] [mailto:open- >>[email protected]] On Behalf Of Mary >>Llewellyn >>Sent: Monday, February 06, 2012 3:46 PM >>To: [email protected] >>Subject: [OPEN-ILS-GENERAL] Vandelay 2.2. question >> >>Hi all, >> >>We've just installed Evergreen 2.2 on a test server, and I'm starting >>to look at Vandelay's new features. The first problem I'm running into >>is trying to set up a Record Match set using tag 001 as a match point. >>Tag 001 has no subfields, but the Working Match Point won't allow me >>to add a tag without a subfield. I've thought about using the OCLC >>number from tag 035, but that number has no "ocn" or "ocm" prefix, and >>I expect that may cause a problem if we hit some other system control >>number in that field. Similarly, I'd like to include values from tag >>019 subfield a (Obsolete OCLC number) as a match point, but the >>presence/absence of the prefixes in those numbers may cause a problem, >>too. >> >>Any advice out there? >> >>Thanks, >> >>Mary >> >>Mary Llewellyn >> >>Database Manager >> >>Bibliomation, Inc. >> >>Middlebury, CT >> >>[email protected]
