Disclaimer: never done this from Python, but lots and lots of BatchCat work.
I believe you're missing the CatLocationID parameter - at least, your
example code has only 6 parameters but should have 7:
* RecordID
* MARCRecord
* DateTime (of update/creation)
* CatLocationID
* RelatedRecordID (the bib id from 004)
* HoldLocationID
* OpacSuppress
(source: BatchCat 9.0 PDF)
CatLocationID is the "cataloging location", which can be seen in the Cat
client on the History tab. It's the location used by editors when they log
into the Cat client, though it has little or no actual functionality -
basically just shows that some operator from the Main or Medical or History
library did that particular edit.
At UCLA, we have a systems-office location which I use in all of the
batchcat programs I write. Makes it easy to filter out "my" batch edits
from reports, and reassures catalogers that I (or my programs) am
responsible for all those edits they don't remember making....
If "459" really is your cataloging location (parameter 4), then you're
missing the HoldLocationID (parameter 6), which should be the numerical id
corresponding to what's in your 852 $b.
Hope this helps!
Andy Kohler / UCLA Library IT / [log in to unmask]
On Tue, Sep 8, 2015 at 8:31 AM, Geoffrey Spear <[log in to unmask]> wrote:
> (Apologies for the crosspost; I'm not sure if this a BatchCat specific
> problem or I'm doing something dumb with pywin32...)
>
> Have any of you had any luck using BatchCat from a Python script?
>
> A few years ago, I managed to get AddItemStatus working fine using
> win32com.client (from the pywin32 library), but trying to use
> UpdateHoldingRecord is behaving oddly
>
> I'm doing something like:
>
>
> import win32com.client
> import arrow
>
> bc = win32com.client.Dispatch("BatchCat.ClassBatchCat")
> bc.Connect(AppPath=r'C:\Voyager', UserName='myusername',
> Password='mypassword')
>
> mrec = thing_that_gets_a_MARC_record()
> result = bc.UpdateHoldingRecord(int(mrec.mfhdid), mrec.record.as_marc(),
> arrow.now().datetime, 459,
> int(mrec['004'].data), mrec.suppressed)
> print("result:", result)
>
>
> with the output
>
> result: (23, 6990816, u'00449cy a22001094
>
> 4500001000800000004000800008005001700016008003300033852008000066856016700146866002600313\x1e6990816\x1e6935429\x1e20130926071356.0\x1e1203285p
> 6 |001bbeng0120328\x1e8 \x1fbfalkwebp\x1fhHSL Online Journals\x1fxULS
> Site License\x1fxserhold updated:mk,3/28/12\x1e40\x1fzAccess via Academic
> Search Premier for Pitt users\x1fuhttp://
>
> pitt.idm.oclc.org/login?url=http://search.ebscohost.com/direct.asp?db=aph&authtype=ip&jid=FM9&scope=site\x1e41\x1f80\x1fav.28-32(2000-2004)\x1e\x1d
> ',
> <PyTime:9/8/2015 10:34:32 AM>, 459, 6935429, 0, False)
>
>
> Error 23, according to the documentation, means I've provided an invalid
> location ID. However, "falkwebp" is a valid location, and indeed I'm able
> to write this exact MARC (as far as I can tell) via a Perl script.
>
> I'm wondering if there's some kind of encoding problem; as_marc() returns a
> bytestring, but the return value seems to indicate that the client thinks
> it was called with a unicode version of the MARC (although the bytes look
> correct). I ran this with Python 3, as well, with the same output except
> for the leading u, so maybe pywin32 is doing some automatic decoding and
> that's breaking things?
>
> It seems suspicious that the error is about the location code, rather than
> BatchCat thinking the MARC is just invalid if it's getting encoded in such
> a way that the 852 subfield b is being misread. I wish I could get it to
> tell me what location it thinks I'm trying to use.
>
> Any suggestions would be appreciated.
>
> --
> Geoffrey Spear
> Metadata Manager
> Health Sciences Library System
> University of Pittsburgh
>
