Polaris Canned Reports - Gotchas and Warnings

Clearinghouse Repository
,
1

After some discussion on the Discord, followed by some lessons from the real life, I wanted to start a running list of canned reports in Polaris and some of their pitfalls. Many, if not all, of the Polaris canned reports haven’t been touched in well over a decade and, more and more often, I’m running into issues where the reports aren’t up to modern standards, or they have logical issues, or both. Over the last five years I’ve found myself recommending these reports far less frequently and, within the last year, I’ve started suggesting that librarians don’t use them at all.

I’ll throw updates around here as I find some issues — but if you know of a report that is, for some reason, dodgy or it there’s something about it that users should know — feel free to add the information.

3 Likes
2

Patron Code Statistics

This report is, at its core, a circulation report and it should be reporting circulation based upon unique patron codes. However, we recently ran into an issue with this when comparing the results of this report to data pulled from the PolarisTransactions database. We were looking for a count of unique patrons who checked out anything during the last calendar year. And we wound up in a situation where we needed to explain to the Director and the Library Board why these numbers would be different. The problem lies right here:

INNER JOIN PolarisTransactions.Polaris.TransactionHeaders TH with (NOLOCK)
    ON (TD.TransactionID = TH.TransactionID and TD.TransactionSubTypeID = 7 )

You numbers will be different because your patrons will move from one patron code to another over the course of a year. You’ll likely see a lot of this when juveniles age into adults and their patron codes are updates. Any patron who switches their patron code during your time span will show up multiple times in your report.

The thing to remember is that this report doesn’t count patrons, it’s counting patron codes.

I wouldn’t call this report broken, but it’s definitely something to be aware of. Especially if you wind up comparing circ numbers from other sources.

2 Likes
3

Circulation by Postal Code

This one is weird, because it might work fine for smaller to medium libraries, but larger libraries with high circulation need to be aware that they might be missing data in this report. Within the stored procedure, which works with the PolarisTransactions database, you’ll find this code:

DECLARE @MinID INT, @MaxID INT

	SELECT @MinID = MIN(TransactionID)
	FROM PolarisTransactions.Polaris.TransactionHeaders WITH (NOLOCK)
	WHERE TransactionTypeID = 6001
	AND TranClientDate BETWEEN @BeginDate AND @EndDate

	WHILE @MinID IS NOT NULL
	BEGIN
		SELECT @MaxID = @MinID + 500000 --500,000

This creates a MinID variable that’s populated by the first TransactionID that is a 6001 TransactionTypeID (Item Checkout). After that, the MaxID variable is derived by adding 500,000 to the MinID. That’s not 500,000 checkouts, that’s simply adding 500,000 to the TransactionID.

The problem is, what if you’ve had more than 500,000 transactions between your first 6001 TransactionID and the last 6001 TransactionID? For a library with high circulation numbers, this could be a problem and it would get worse depending on the length of the time between your beginning and ending dates. Because later on in the query, the MaxID and MinID are used as limiters alongside the BeginDate and EndDate.

1 Like