(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
