Some of our Polaris records for Overdrive items are not being removed automatically when the Overdrive item is weeded from our collection. Is anyone else experiencing this? Do you have a work around?
I think this can be common depending on the size of your collection. If you’re not on the very latest release of Polaris (7.4), I would also expect problems as I know there have been major changes in the Overdrive syncing process to improve performance and reliability.
We are just about to update to 7.4 next month. In your experience, will that improve or worsen the situation?
7.4 should improve things, but I don’t know if there are additional patches that should additionally be applied @dwisch might have some insights. They’ve been heroically working to improve this process.
Using the weeded report from Overdrive Marketplace, I was able to match up the Reserve ID number that Overdrive uses with the Vendor Object Identifier in Polaris and get the Bib ID #’s I need to delete from Polaris, but those are in an Excel sheet. I’m hoping for a shortcut that won’t involve manually deleting 2500 records one by one. Polaris has offered to create a bib record set based on last circulated date, but I am leery of that and saving it for last resort.
Assuming the content-ids match your 037 $a, you could use the following Bib Find Tool SQL (it will likely be slow):
select bt.BibliographicRecordID
from Polaris.Polaris.BibliographicSubfields bs
join Polaris.Polaris.bibliographictags bt on
bs.BibliographicTagID = bt.BibliographicTagID
where bt.TagNumber = 37 and bs.Subfield = 'a' and bs.data in
(
'7FD33249-605F-46AC-B133-7F2C72416F97', --replace with contentIDs
'7FD33249-605F-46AC-B133-7F2C72416F97' --the last contentID should NOT end with a comma
)
There is probably a maximum number of contentIDs you can get in there, but you might be able to do it via batches that way.
Using Innovative’s method, if you did happen to delete something you still owned, it should in theory add that record back in once the sync process noticies it missing.
Thanks, Wes! I will try that out in a small batch.
Yes, Innovative said that also, but I was still leery and it wasn’t a solution for the future. If this query works, I could use it each week when I get the weeded list from Overdrive.
Are your items being deleted, but not the bibs? I think that’s normal–we regularly (weekly?) delete Overdrive bibs with no items using this SQL query:
SELECT DISTINCT br.BibliographicRecordID
FROM BibliographicRecords br (NOLOCK)
LEFT JOIN CircItemRecords cir (NOLOCK)
ON cir.AssociatedBibRecordID = br.BibliographicRecordID
WHERE br.BibliographicRecordID IN
( SELECT re.BibliographicRecordID
FROM ResourceEntities re (NOLOCK)
WHERE re.VendorAccountID IN
( SELECT VendorAccountID
FROM VendorAccounts va (NOLOCK)
WHERE va.vendorID = 5 ) )
AND cir.ItemRecordID IS NULL
(Pretty sure this was borrowed from @mhammermeister when we first went live on Polaris!)
If your items are also not being deleted as expected, I can 100% sympathize! We have experienced this as well over the last few years. Fortunately, the Polaris dev team has been working to actively improve processes on the back end over the last year. We’ve seen some significant improvements in eContent processing, particularly over the last couple months.
Here are the odds and ends (that I know of) that have been addressed over the last year in 7.2 and 7.4, according to my notes. (Disclaimer: These are my personal notes and not official release announcements from iii! I hope I am not misrepresenting any of the technical details, which can be very complicated!)
2022/Polaris 7.2:
- iii refactored the process that populates the properties dialog in the vendor account workform. The process was being called several (thousands?) of times during the night instead of just once at the end of the vendor account sync.
- iii fixed a bug where item records were not being properly deleted when copies were weeded or expired. (Our team deleted a backlog of over 160,000 unavailable Overdrive items prior to the patch being applied!)
- iii updated the version of the OverDrive API used for syncing item availability to support batch processing. Polaris still needs to call the API to check the number of copies and status for all OverDrive items, but starting in 7.2, the API calls are made in batches to increase performance (instead of calling single records at a time)
- iii discovered fixed a bug with the OverDrive last sync date in Polaris. The integration was always designed to only grab “new” titles after the initial data sync. The bug iii discovered is that failures in the overnight process could cause the last sync date to be wiped. If the date was wiped for a particular vendor account, Polaris would attempt to sync all titles the next time around for that vendor. This caused a lot of overhead in the nightly process and resulted in weeded bibs being added back into the database.
- iii applied a patch to our server (currently on 7.2) to improve processing time for Axis 360 overnight sync. It was taking over 24 hours for our Axis 360 econtent to sync, which was in turn causing Overdrive delays. We've seen drastic improvements with this patch--our Axis 360 sync went down to 1 hour. Prior to this patch, Overdrive econtent synched once every 2-4 weeks. We now see almost daily Overdrive imports. This patch/fix is included in Polaris 7.4.
- I believe 7.4 includes a fix for a separate overdrive item record deletion issue--I don't have details on this, just a note from Samantha Quell saying the patch noted above included an additional fix for this issue
Long story short–hopefully you’ll see an improvement with your 7.4 upgrade!
2 Likes