New Build, New Problems
We downloaded a new iBorrow build on Wednesday, February 21. We got some good bug fixes, some nice enhancements, and a few new bugs. So far, these seem to be kind of gnat sized bugs, rather than the giant cockroaches we’ve gotten a few times in the past. Here, for your amusement and edification, is what they are and what we know about them.
Lender cannot decline requests
If the borrowing library has no Lender of Last Resort in the library profile that Matt and I originally set up for them, and if there is no lender on the far side of you in the ROTA, you will not be able to decline their requests when they show up at your library. SirsiDynix has found the cause of this problem, and it will be fixed in the next build. Meanwhile, there are two workarounds.
Workaround Number One is to just leave the requests you would normally decline alone. They should “age” out of your Fill Loan or Mediate Loan work space in a few days. Exactly how many days depends on what you asked us for when we initially set you up. Remember what your Mom told you—“Ignore them and they’ll go away.”
Workaround Number Two is to give these libraries a Lender of Last Resort for a while. Usually we use OCLC for that, and the affected libraries may want to try that approach anyway. But we can put anything in there, and you’ll be able to decline again. But the ones you decline will go to that lender. Ken Adams and I are still working on the details, but I think we could set up one of the libraries who is not yet using iBorrow (Sanibel, maybe?) as their LOLR, and set the aging threshold at one day. So, anything you declined would bounce to there for a day, then reappear at the next participant in the ROTA. We may have that set up by the time you read this.
‘Ear’ File Problem
If you had a file that lived on your OPAC server and spent all its time listening for NCIP messages to come from URSA/iBorrow, what would you call it? How about an ‘Ear’ file? That’s the common name at SirsiDynix for the “NCIP Responder File” that we have on our local servers. We should probably call it an “Ear and Brain File”, because it has to interpret what URSA tells it after it hears it. And our current Ear file has a brain cloud.
So, many of you are having trouble filling requests in Fill Loan, because the Ear file keeps saying, “Huh? What was that middle part again?” whenever URSA sends it an instruction. I’ll tell you why in a minute, but the good news here is that we don’t need to wait for a new build to fix this. We can load a new Ear file as soon as SirsiDynix can whip one up. The catch is that every affected system has to load the Ear file separately. Loading the Ear file at Sunline will not help Hillsborough.
The cause behind this problem is that all Horizon systems use a computer language called SQL (Structured Query Language). There are three dialects of SQL: Solaris, MS, and Sybase. Our current Ear file has trouble with the Sybase dialect. And Sunline uses Sybase SQL. So, we think, does Palm Harbor. And maybe Hillsborough and Polk. We’re still checking.