OPAC issues
March 8, 2016 9:45 AM Subscribe
What is the cause of errors in a small library OPAC? Technical services librarians and database experts, your wisdom is appreciated.
This is a small library with about 14,000 bibliographic records and 17,000 holdings. The remotely hosted OPAC is Mandarin M3 (Oasis) v.2.9.5, running on Windows. The librarian (me) does everything and has no dedicated catalogers or technical services personnel on site. Several people held the position before me, with varying levels of technical ability. I don't have any way of tracking them down. I confess that I myself don't know anything about database architecture (just that they have front and back ends). I know how to operate the Oasis front end, import MARC records, and customize them to a degree, but I have no access to the back end.
Typical errors:
An item (book) is listed in the Catalog module as being on loan, with an old due date, but it is on the shelf. It is not a case of an item that was simply reshelved without being checked back in. All of these books erroneously "on loan" have been checked out at some point and then returned. When you "return" such an item in the Circulation module, a flag pops up stating that the item is not on loan. After doing this, the item appears in the Catalog module as available.
I have found hundreds of books on the shelf that were recorded erroneously as "on loan."
M3 support tells me that the problem is in the MARC 993#x subfield and that it can be reset to 0 to eliminate the problem. I've had M3 support clean out this problem, but I'd like to know how the problem arose to begin with.
There are some bibliographic records for which there are no holdings. I suspect this is an user error, and that someone imported MARC records by accident or on purpose (hoping to buy the books later) or were interrupted and failed to complete the records. Or holdings may have been purged as part of weeding, but the user forgot to do the same with the biblio. I found a few of these books on the shelf but others appear to be true ghosts.
This is a small library with about 14,000 bibliographic records and 17,000 holdings. The remotely hosted OPAC is Mandarin M3 (Oasis) v.2.9.5, running on Windows. The librarian (me) does everything and has no dedicated catalogers or technical services personnel on site. Several people held the position before me, with varying levels of technical ability. I don't have any way of tracking them down. I confess that I myself don't know anything about database architecture (just that they have front and back ends). I know how to operate the Oasis front end, import MARC records, and customize them to a degree, but I have no access to the back end.
Typical errors:
An item (book) is listed in the Catalog module as being on loan, with an old due date, but it is on the shelf. It is not a case of an item that was simply reshelved without being checked back in. All of these books erroneously "on loan" have been checked out at some point and then returned. When you "return" such an item in the Circulation module, a flag pops up stating that the item is not on loan. After doing this, the item appears in the Catalog module as available.
I have found hundreds of books on the shelf that were recorded erroneously as "on loan."
M3 support tells me that the problem is in the MARC 993#x subfield and that it can be reset to 0 to eliminate the problem. I've had M3 support clean out this problem, but I'd like to know how the problem arose to begin with.
There are some bibliographic records for which there are no holdings. I suspect this is an user error, and that someone imported MARC records by accident or on purpose (hoping to buy the books later) or were interrupted and failed to complete the records. Or holdings may have been purged as part of weeding, but the user forgot to do the same with the biblio. I found a few of these books on the shelf but others appear to be true ghosts.
The first part could be difficult to resolve because I believe 993 is a local use field so will be used for different things in different library management systems. I don't do MARC myself though so can check with my acquisition colleagues tomorrow.
From a systems librarian perspective, it sounds to me like the current loan flag in the database (which has nothing to do with the MARC record) for some items has become corrupt so the original discharge didn't fully complete and the system is marking it as on loan and also not on loan, which leads to the situation where discharging the item again both triggers the not on loan message and removes the conflicting flag. This can just be a side effect of an old database that doesn't have a lot of technical maintenance/eyes on it. Has the work that was done by your supplier resolved the issue?
In regards to the second part, yes, the missing holding are probably the result of incomplete imports or weeding. Most LMSs have a script or daemon that automatically suppresses records without holdings as general housekeeping but that has been something I have done manually when the system doesn't do it automatically/the library was tiny, on the grounds that as I went through the physical stock, I could unsupress if I found an item or suppress when something clearly no longer physically existed. Could your supplier provide this function as custom work for you or is that sort of custom development not feasible? Otherwise, it is a (tedious) manual housekeeping task.
posted by halcyonday at 10:36 AM on March 8, 2016 [1 favorite]
From a systems librarian perspective, it sounds to me like the current loan flag in the database (which has nothing to do with the MARC record) for some items has become corrupt so the original discharge didn't fully complete and the system is marking it as on loan and also not on loan, which leads to the situation where discharging the item again both triggers the not on loan message and removes the conflicting flag. This can just be a side effect of an old database that doesn't have a lot of technical maintenance/eyes on it. Has the work that was done by your supplier resolved the issue?
In regards to the second part, yes, the missing holding are probably the result of incomplete imports or weeding. Most LMSs have a script or daemon that automatically suppresses records without holdings as general housekeeping but that has been something I have done manually when the system doesn't do it automatically/the library was tiny, on the grounds that as I went through the physical stock, I could unsupress if I found an item or suppress when something clearly no longer physically existed. Could your supplier provide this function as custom work for you or is that sort of custom development not feasible? Otherwise, it is a (tedious) manual housekeeping task.
posted by halcyonday at 10:36 AM on March 8, 2016 [1 favorite]
For biblio without holdings I agree they were probably weeded out. Or, before your current ILS there may have been an importation of records that went wrong. Welcome to the problem of legacy systems in Libraries :)
Can you do an inventory? You said it is small, which is relative, but I used to do an inventory once a year of 20,000 items. Now I am in a larger system I have scheduled the inventories by section.
To a certain extent, you need to prioritise what problems pre-dated you, and which problems are occurring now (I suspect more problems predate you). A tedious task, but keep a log of what the problems are so you can identify patterns.
posted by saucysault at 10:40 AM on March 8, 2016 [2 favorites]
Can you do an inventory? You said it is small, which is relative, but I used to do an inventory once a year of 20,000 items. Now I am in a larger system I have scheduled the inventories by section.
To a certain extent, you need to prioritise what problems pre-dated you, and which problems are occurring now (I suspect more problems predate you). A tedious task, but keep a log of what the problems are so you can identify patterns.
posted by saucysault at 10:40 AM on March 8, 2016 [2 favorites]
Are all the old due dates on these problematic things from the same period? Maybe checkin failed for a time?
Also, what is your ILS? Have you had this same ILS for a long time? To me this sounds like the sort of thing which happens when data gets moved from one system to another.
posted by Riverine at 11:27 AM on March 8, 2016
Also, what is your ILS? Have you had this same ILS for a long time? To me this sounds like the sort of thing which happens when data gets moved from one system to another.
posted by Riverine at 11:27 AM on March 8, 2016
The folks on the Code4Lib listserv be able to help... https://listserv.nd.edu/cgi-bin/wa?A0=CODE4LIB
posted by kzwa at 11:45 AM on March 8, 2016
posted by kzwa at 11:45 AM on March 8, 2016
It's been about 5 years since I was using a Mandarin ILS, but yeah, we had that kind of problem too. I agree with the comments that it's likely related either to a failed checkin or a holdings issue.
Mandarin always struck me as really finicky about checkins: if the cursor is not in the right place, it beeped like it worked, but didn't actually process, and you could go through a cart of things to shelve before realising the problem. Our parent volunteers often didn't notice, and we'd track down problem later. I vaguely remember there were particular glitches about things that got marked missing or other categories of 'not returned' which were later returned.
I found doing a regular inventory helped clear a lot of the problems out - it required manual editing of some records, or finding the item, checking it out then in again and seeing if that cleared the problem - but over time, it made the problem go away.
posted by modernhypatia at 11:47 AM on March 8, 2016
Mandarin always struck me as really finicky about checkins: if the cursor is not in the right place, it beeped like it worked, but didn't actually process, and you could go through a cart of things to shelve before realising the problem. Our parent volunteers often didn't notice, and we'd track down problem later. I vaguely remember there were particular glitches about things that got marked missing or other categories of 'not returned' which were later returned.
I found doing a regular inventory helped clear a lot of the problems out - it required manual editing of some records, or finding the item, checking it out then in again and seeing if that cleared the problem - but over time, it made the problem go away.
posted by modernhypatia at 11:47 AM on March 8, 2016
M3 support tells me that the problem is in the MARC 993#x subfield and that it can be reset to 0 to eliminate the problem. I've had M3 support clean out this problem, but I'd like to know how the problem arose to begin with.
My main experience has been with cataloging and not with circulation, but I agree the problem may have occurred during importation/transfer of data. I've had to manually edit catalog records coded incorrectly after a system switch.
993 is not a standard MARC tag and is used internally for information on local holdings. It can sometimes be used for non-bibliographic information, based on an agreement between the library and vendor. Since the 993 indicator (I think you meant indicator, not subfield) has been reset to 0 and you're still having problems, my guess is the problem lies elsewhere - maybe in the 852, 863-865, and/or 876-878 fields. I've had to manually change indicators, subfields, and subfield data for those. I would suggest calling Mandarin technical support.
posted by mountainpeak at 5:08 PM on March 8, 2016 [1 favorite]
My main experience has been with cataloging and not with circulation, but I agree the problem may have occurred during importation/transfer of data. I've had to manually edit catalog records coded incorrectly after a system switch.
993 is not a standard MARC tag and is used internally for information on local holdings. It can sometimes be used for non-bibliographic information, based on an agreement between the library and vendor. Since the 993 indicator (I think you meant indicator, not subfield) has been reset to 0 and you're still having problems, my guess is the problem lies elsewhere - maybe in the 852, 863-865, and/or 876-878 fields. I've had to manually change indicators, subfields, and subfield data for those. I would suggest calling Mandarin technical support.
posted by mountainpeak at 5:08 PM on March 8, 2016 [1 favorite]
Oh sorry, you mentioned M3 support and I assumed you meant M3 customer support not Mandarin technical support. But I just realized you must have already talked to Mandarin technical support if they tried to fix the 993 problem. I would still try talking to tech support again, based on the added information you now have.
posted by mountainpeak at 5:20 PM on March 8, 2016
posted by mountainpeak at 5:20 PM on March 8, 2016
I am a cataloger, IANYC (I've always wanted to do that!) -- there are two very plausible explanations given upthread for the incorrect circ status on your items, either there was a problem with data migration or the checkin interface is finicky and doesn't check things in sometimes and it's hard to notice. I like that theory personally, especially if the due dates are all over the place (are they?) -- if they're all around the same timeframe that would more likely point to a data migration error.
I agree that the best way to solve it is to do an inventory or to undertake a project to check everything in -- do you have a volunteer or intern who could help you with such a thing? Your library is small, it wouldn't take that long.
As far as bibs with no items attached... that happens in every catalog ever. Most of ours are weeded items that didn't get their bibs deleted, yeah, though I will confess that I've been guilty of pulling records in and failing to attach items from time to time and I'm sure I'm not the only one. If you also have database maintenance tasks that, for instance, delete items in missing, lost, etc. status after a while that could be a culprit too. What I'm saying is you probably have multiple things happening that could lead to empty bibs. Can you run a query to bulk-delete them? That's what I do.
posted by rabbitrabbit at 9:52 PM on March 8, 2016 [1 favorite]
I agree that the best way to solve it is to do an inventory or to undertake a project to check everything in -- do you have a volunteer or intern who could help you with such a thing? Your library is small, it wouldn't take that long.
As far as bibs with no items attached... that happens in every catalog ever. Most of ours are weeded items that didn't get their bibs deleted, yeah, though I will confess that I've been guilty of pulling records in and failing to attach items from time to time and I'm sure I'm not the only one. If you also have database maintenance tasks that, for instance, delete items in missing, lost, etc. status after a while that could be a culprit too. What I'm saying is you probably have multiple things happening that could lead to empty bibs. Can you run a query to bulk-delete them? That's what I do.
posted by rabbitrabbit at 9:52 PM on March 8, 2016 [1 favorite]
This thread is closed to new comments.
posted by bad grammar at 9:47 AM on March 8, 2016 [1 favorite]