Notes on Deletions Files
If you sent a file for deletions during September you should hold onto your backup copy a bit longer. I have heard from several libraries wanting to know if the deletions for September are complete and the files can be discarded.
We received 150+ files of record numbers for deletion in September. The files that were correctly formatted and processed without issues were done on October 1st. There were 60 files that didn't process correctly and I am working my way through those to determine what the problem is and how it can be resolved.
So far I have found several patterns:
- Files that do not have the cells formatted as "numbers, 0 decimal places) generate processing errors.
- Fles that include bib#s that the library sending the file doesn't actually have a holding on (there were a LOT of these) weren't processed because the final "X items will be deleted" message I get in processing doesn't match the file and I stopped them to find out why.
- There were also some that had more than I expected, but those were because the libary had multiple holdings on the same bib#. Those could be verified at this end and the holdings were deleted. Note that if you include a bib# in your deletions list all your holdings on that record will be deleted. If you are just wanting the duplicate to go away you shouldn't worry about it as we run a de-duping script periodically to clean these up anyway.
It did become clear in working on the September deletions that if each library (after we run their 20-record test file) sent us a single spreadsheet with all their deletions in it (up to 999 per file) it would save us a lot of work over processing multiple small files.
No comments:
Post a Comment
Comments on this blog are welcome, but they are moderated. Signed comments that we feel make a positive contribution to the discussion will be posted.