« Pirke Avot chapter two, verse eighteen: wickedness | Main | Three Plays »

Grrrrrrr. Also, Feh.

Blogging will be short this week, as (a) there are lovely real-life things going on at home, (2) my library director has gone crazy at work, and (iii) there isn’t really a third opportunity for YHB to write for this Tohu Bohu.

I will, however, report that I have survived another evil webinar. While I suppose that there is some comfort in knowing that it is not just some sort of blind stupidity on the part of circ here that prevents us from writing useful and accurate reports, it would be nice if the thing that prevents us were not simply that the report-writing module does not work properly. Gr.

Also, when I was complaining about web training the other day? I forgot to mention that high-pitched giggling is not good trait in an on-line trainer.

But here’s the thing: once a month, in order to do the billing, we here in circ need a sheet of paper for each patron that is being billed, which should have on it all outstanding fines for overdue books, and the titles, bar code numbers and call numbers of those books, as well as the amount of the fines and certain information about the patron. In our old system, which I won’t name, although it does have the same name as a series of heliosphere probes, in order to get this information, we printed out a list of items, and then printed out individual sheets for each patron, and then hand-wrote the call numbers because there was no way to create a report that would give us what we wanted. Well, and actually, it was that creating such a report would have been incredibly laborious and annoying, more so (believe it or not) than doing it the way I’ve described.

Well, that was crazy. And it was, I’m afraid, typical of the report-writing problem in our old system.

Now, however, we have left that software behind, and we have a new, new, new ILS. My hopes for this were high, but my particular hope for convenient and easy report-writing were high. That would make our lives ever so much easier.

In our shiny new system, we cannot actually get a list of items that require billing. Well, not an accurate list.

Does that seem like a flaw?

Because to me, it seems problematic.

But leaving aside the accuracy of the list, there’s this: we cannot create a report that has both book titles and the name of the person who has them out. The two pieces of information—patron name and item title—cannot appear in the same report. They just can’t. We can get the book’s ISBN number, should it have one, on the report with the Patron name, but not the title. Or the call number, for all of that.

And the thing that really, really astonishes me is that ours was the third session by our webinar host, and the first time that issue had come up.

Tolerabimus quod tolerare debemus,


The two pieces of information—patron name and item title—cannot appear in the same report.

Is it a privacy concern?

Is it a privacy concern?

No. I can be sure about this for a few reasons: (1) the trainer, when asked to show us an example of such a report, said brightly Yes! I can do that! (having failed at the first two reports asked of her) (and before failing at that as well); (ii) while it does make sense that a list of a patron's previous borrowings would be a problem, there is nothing in our privacy policy that says that staff are not allowed to know what patrons have currently checked out, and (C) the system actually prides itself on keeping that information available. F'r'ex, Patrons can look at their history to see what they have checked out, etc, etc. We have had it customized to 'anonymize' the data for books that have been returned, but have not implemented that bit because we're not actually sure that the data transfer from the old system to the new one has everything correct, and in the interim, we have found it very useful to have full records of everything since the changeover.

Actually, we are damn sure that some of the transfer was fucked, but we don't know the extent of it. I suspect hu-u-ugely fucked (that's a tecknickle term) but I suspect that is true of all databases…



Oh, oh, oh.

Goodness gracious, I am so sorry. That well and truly sucks. And from what little I know about databases and database design, I can't quite parse how it's even possible that such a report is impossible.

Remind me again (privately, if need be) of what ILS this is? I may have a connection or two that I can call in on this. At the very least, if it's the ILS that I think it is, there's someone I know, who needs to know how colossally bad your trainer has been.

Well, and it's not theoretically impossible for such a report to exist. I may, in fact, be exaggerating to vent my frustration.

The situation is in fact thusly: There are three ways to run reports. First, there are certain canned reports. Those are the ones that are giving us highly questionable results, although I don't think that is the problem of the reports, so much as the data fuckup. Anyway, those reports cannot be edited or changed, other than when they allow for the input of certain parameters.

The second method for report-running is the Guided Report, in which the wizardy wizardy wizard asks the user to choose incomprehensibly labeled fields to report on. For reasons unbeknownst to YHB, the first decision is whether to run a Circulation or a Cataloguing report. Circ reports allow the use of the Patron Name. Cataloguing reports allow the use of the Item Title. Never the twain shall meet.

The third method is to just type in a bunch of SQL gibberish. Now, here, clearly, it should be possible to run that report I'm looking for. Only, see, YHB doesn't know SQL. And yes, clearly I will be learning it, curse everything, but I will not be learning it between now and the beginning of the semester.

Now, the trainer was looking for a report of the second type, to show us how the Guided Reports work, and she clearly thought that she could run it that way. Having failed to do that, she tried to quickly put together the SQL statement, quickly (but not quickly enough) gave up and said she would send us the SQL statement afterward.

And the next day, she did in fact send us a pile of SQL gibberish, which did not run as a query in our software at all.


The good news is that if you do learn SQL, you'll have acquired a highly marketable skill.

Ah, I see now. Yes, I loathe and detest those wizardy wizards because they never quite do what I want them to do. Which is why, when faced with a situation like yours, I think I'd be learning myself some SQL. (I've finally come to terms with the fact that I'm really a command-line user at heart.)

The other good news is that SQL isn't really all that hard. At least, it wasn't when I learned the basics in my database class(es?) at library school.

That sucks, and it's bizarre that the standard reports would not include something so obvious and basic. It's ridiculous that you should have to use SQL to get that info.

But fwiw, the SQL to get that info may be pretty straightforward, if they've done a decent job of designing the tables. Of course, they may not have.

...Of course, the other problem with this setup is that by giving you access to the SQL layer, they may be giving you a lot more power than would be ideal. In particular, I'm hoping that they only give read access to ordinary SQL users, because it's very very easy for a SQL user with write access to accidentally destroy vast quantities of data. I've done it on a number of occasions despite being very careful about these things. This is why I always do a full database backup before each session in which I'll be typing any SQL command that modifies anything, but somehow I doubt that'll be feasible for your system.

Comments are closed for this entry. Usually if I close comments for an entry it's because that entry gets a disproportionate amount of spam. If you want to contact me about this entry, feel free to send me email.