Related product I-Share

Suggested Priorities for Bibliographic, Holding, and Item Record Maintenance

Return to Suggested Priorities main page

General good practice

G1. Use all of Voyager’s validation options in the cataloging client.

Turning on (i.e., not bypassing) the validation functions in Options --> Preferences --> Validation tab in the cataloging client will help assure that headings, MARC coding, and ISBN/ISSNs are valid for records as they are added to or updated within your database.

G2. Consider implementation of OCLC’s WorldShare Metadata Collection Manager Record Updates Service

This service allows libraries to replace bibs in their catalogs with new versions when certain improvements have been made to the master record in OCLC.  For further details, see OCLC’s WorldShare Metadata Collection Manager Record Updates Service in the I-Share Environment

Projects to do Frequently

F1. Eliminate duplicate item barcodes.

Resolving these problems is very important for circulation and interlibrary loan service. Duplicated item barcodes force staff to select from a list of items when a barcode is scanned. This is particularly problematic for items sent to fill UB requests, because the item information available to the borrowing library is limited. Duplicated item barcodes can also result in the wrong item being used to fill a UB request.

To help prevent future instances of this problem, it is strongly recommended that all cataloging and circulation operators enable the client preference to “Check for Duplicate Item Barcodes.”

(F1.A) Pre-Packaged report: “Duplicate Item Barcodes” finds cases where the same barcode has been used on more than one item.

(F1.B) Shared SQL (Item Records: Barcode category): "Find holding and item data for a given barcode" is a query that helps with the resolution of problems found by the “Duplicate Item Barcodes” pre-packaged report. This query prompts for an individual barcode number, and outputs the data needed to identify the item records with identical barcodes.  This query may be most helpful when there are only a few duplicated barcodes found in a database.

<NEW 08/2011> (F1.C) Shared SQL (Item Records: Barcode category): "Find holding and item data for all duplicated barcodes" is another query designed to help with the resolution of problems found by the “Duplicate Item Barcodes” pre-packaged report.  This query uses the Duplicate Item Barcodes query as a table, and then outputs the data needed to identify all of the item records with identical barcodes.  This query may be most helpful when there are many duplicated barcodes found in a database.

F2. Correct barcodes that do not contain the right number of digits, or add active barcodes to item records that lack them.

From time to time, barcode readers (or typists) skip or repeat digits.  And from time to time, staff forget to add the barcode number to the item record during processing.  Finding and fixing these cases quickly will save trouble at the circulation desk and ILL office.

(F2.A) Shared SQL (Item Records: Barcode category): “Item barcodes with invalid length.”  The query prompts for the correct number of digits for your library’s item barcodes.

(F2.B) Shared SQL (Item Records: Barcode category): “Items with no Active barcodes.”  The query finds item records with no barcode at all, or only barcodes with a status of inactive.  Of course, some items without barcodes are legitimate (e.g., rare book room materials or other non-circulating collections), but this query may find item records where an active barcode should be added.

F3. Eliminate “error” item type code.

“Error” item types could have been created during the library’s data conversion to Voyager, or from ongoing bulk import jobs where the incoming data does not match a “real” entry in the mapping table.  Items with the error item type code often do not generate the proper due date when charged, because many libraries profile them to have restricted loan policies.  Finding and fixing these cases will save trouble at the circulation desk and ILL office.

Shared SQL (Item Records: General category): “Find error item type code."

F4. Revise item record variable fields containing double quote character.

There is a newly discovered bug in WebVoyage Classic, whereby the presence of a double quote character (i.e., “) in an item record variable field will prevent the UB request form from populating correctly in the I-Share Union Catalog.  This means that patrons from any library cannot place requests on any titles in the UC that have a double quote character in the Enumeration, Chronology, Year, Caption or Freetext fields of the item record, no matter which library has that data in their item record.

Shared SQL (Item Records: General category): “Item records containing double quote.”  This query finds item records linked to bibs that are not OPAC suppressed that contain the double quote character in any of the item record variable fields.

Shared macro (Item Record Maintenance section): “Changeitem_doublequote.mex.”  If you have too many of the item records to fix manually, this macro can help with cleanup.

F5. Resolve cases where item types are not consistent with an item’s location.

Items with this problem may be circulated inappropriately or for incorrect periods of time.

(F5.A) Pre-Packaged report:  “Item Count by Location and Type.” Running this report will show the number of occurrences of each combination of permanent location and item type.  From this, you can quickly see cases where an item type and permanent location combination may be incorrect, such as a circulating reference book.

(F5.B) Shared SQL (Item Records: General category):  “Items with specific combinations of perm loc and item type” is a query designed to be used in conjunction with the “Item Count by Location and Type” pre-packaged report, and will show you the specific items with questionable combinations, which can then be investigated and corrected.

F6. Resolve conflicts when item records have permanent locations different from the location in the MFHD.

Because location information is independently coded in the MFHD and in the item, sometimes errors are committed that result in conflicting location information.  A common underlying cause of this discrepancy is the use of Voyager Pick and Scan to change the item record’s permanent location without also setting the option to change the holding (MFHD) location. It is strongly recommended to change both locations when using this tool.

WebVoyage version 7 makes this data discrepancy much more noticeable to patrons than previous versions of that public interface.

Shared SQL (Item Records: General category):  “Item records with perm locs different from the MFHD loc”.  Revised summer 2009 to include the item barcode, so that Pick and Scan can be used as part of the fix.

Pick and Scan has functionality to edit both the item and MFHD location.  Pick and Scan requires the item record to contain a barcode, so not all appropriate records may be fixable with this tool.

F7. Evaluate bibliographic records without MFHDs.

These may be “orphaned” bib records left over from incomplete withdrawal or bibs created for ordering that have not had orders placed for them.  Bibs without holdings can be confusing and misleading to patrons and staff.  Note: Some bib records in Voyager cannot be deleted if they are associated with Acquisitions POs.  In these cases, you may need to suppress the bib record instead of delete it.

Shared SQL (Bibliographic Records: General category):  “Bibliographic records without MFHDs

Shared SQL (Bibliographic Records: General category), Acquisitions version: "Bibs without MFHDs Acq main query"

Shared macro (Bibliographic Record Maintenance section): “Del_bibs.mex.”  If it is determined that bib records identified by this query can and should be deleted, this macro can help with cleanup.

F8. Supply missing call numbers in MFHDs with items attached.

If catalogers forget to create a call number, or miscode it in various ways, users will see no call number in the public catalog.

Shared SQL (MFHD Records: Call Numbers category):  “Missing call numbers in MFHDs with items attached

F9. Perform link checking and maintenance on URLs.

For electronic resources, URLs function similarly to a physical item’s call number.  Invalid URLs make the electronic resource unavailable to users via the OPAC.

Each I-Share library is encouraged to evaluate their local requirements for more extensive link checking than is described in this project, and to initiate the best possible solution for their institution.

(F9.A) Shared SQL (Bibliographic Records: General category):  “Bibliographic or MFHD records with typos at beginning of URL”.  This query finds 856 fields in bibs and/or MFHDs that have typographical errors at the beginning of the field, which makes the URL inaccessible.

(F9.B) Requestable via WRO: a re-run of “MFHD_866withURL” which will identify specific holdings records that have at least one 866 field that contains the text string “http”.  URLs in 866 fields are treated as a note, and are not hyperlinked to provide access to the online resource for patrons.  The URL must be stored in the MFHD record’s 856 field in order to be hotlinked.  In October 2017, this server-side report was run for all I-Share libraries; at that time, only 23 of the I-Share databases had any of these “errors,” so it is possible that a re-run of this report will not find any records in your database.

F10. Correct MFHDs missing a call number prefix for a specific location.

Some libraries use a prefix for all items in a specific location.  If the prefix is missing, users may have difficulty knowing where to find an item.

Shared SQL (MFHD Records: Call Numbers category):  " MFHDs missing call number prefix for a specific location

Shared macro (MFHD (Holdings Record) Maintenance section):  “Addmfhd_852k.mex.”  In cases where the prefix needs to be added, this macro is available to help.

F11. Evaluate MFHD call number prefixes for typos or miscoded data.

Some libraries use a prefix for all items in a specific location.  Sometimes the prefix contains a typographical error or is added to the call number proper (852 $h) instead of the subfield designated for prefixes (852 $k).  There is a suite of queries designed to help identify the MFHDs with these types of errors. Be sure to read the description of each query on the Shared SQL page, for more information about the intention of each query.

(F11.A) Shared SQL (MFHD Records: Call Numbers category):  “Odd Prefixes Query 1 – List All Prefixes”.  This make-table query is designed for use by the other queries in the suite.  It creates a table of all MFHDs that have an 852 $k.  This query may take up to several hours to run.

(F11.B) Shared SQL (MFHD Records: Call Numbers category):  “Odd Prefixes Query 2 – Rare Prefixes”.  This make-table query is designed for use by the other queries in the suite.  It creates a table of all MFHDs from Odd Prefixes Query 1 where the prefix is found in 20 or fewer MFHDs.  This query is designed to identify potential typographical errors in prefixes, and is used by the other queries in the suite.

(F11.C) Shared SQL (MFHD Records: Call Numbers category):  “Odd Prefixes Query 3 – MFHDs with Rare 852$k”.  This query compares the tables created by the previous two queries and produces a list of the MFHD IDs that contain the “rare” prefixes found by query 2. These query results can be used to manually correct typographical errors found in 852 $k prefixes.

Shared macro (MFHD (Holdings Record) Maintenance section):  “Changemfhd_852k.mex.”  In cases where the existing prefix needs to be revised, and there are too many records to process manually, this macro is available to help.

(F11.D) Shared SQL (MFHD Records: Call Numbers category):  “Odd Prefixes Query 4 – Prefixes not in 852$k”.  This query takes the list of all prefixes found by query 1 and looks for “normalized” call numbers that begin with the prefix.  A common error is to put the prefix in 852 $h instead of 852 $k.

F12. Correct MFHDs missing a call number suffix for a specific location.

Some libraries use a suffix for all items in a specific location.  If the suffix is missing, users may have difficulty knowing where to find an item.

Shared SQL (MFHD Records: Call Numbers category):  “ MFHDs missing call number suffix for a specific location

Shared macro (MFHD (Holdings Record) Maintenance section):  “Addmfhd_852m.mex.”  In cases where the suffix needs to be added, this macro is available to help.

F13.  Evaluate MFHDs with a mismatch between call number type and 852 field indicator values. <NEW 04/2012>

When a MFHD is saved to the database, Voyager performs normalization on the call number.  Normalization starts with the 852 field’s first indicator, which tells the system what type of call number is stored in the record. For example, an 852 indicator 1 value of 0 (zero) means the call number uses LC classification, and an 852 indicator 1 value of 8 means the call number uses an “Other” classification scheme. 

When the MFHD being saved fails to normalize according to the rules for the call number type, the operator is presented with a message stating that the call number is being saved as an “Other” call number.  When this message displays, the MFHD is saved to the database, the CALL_NUMBER_TYPE index in the underlying Voyager tables is set to Other, but the 852 indicator 1 value in the MFHD record is not changed from its original value.  Because the MFHD is not edited under these circumstances, looking at the MFHD via the cataloging client at a later time offers no clue that the underlying call number type indexing is different from the 852 first indicator’s value.

Some common scenarios for this kind of failed call number normalization are listed below, in the order most often encountered in testing:

1)    The call number is legitimately an “Other” number, but the indicator value is set as though the call number were from a standard classification scheme (e.g., LC or Dewey), often based on defaults set in the cataloger’s client preferences;

2)    The call number prefix is incorrectly coded in $h instead of $k, which usually causes normalization to fail;

3)    The call number is legitimately an LC, Dewey, or other standard classification number, but it contains typographical errors significant enough to cause normalization to fail.

Records that match the third scenario above may prevent the patron from finding the item on the library shelves, and therefore represent the highest priority for correction within this project. Records match the second scenario above will likely have no direct negative effect on patrons, but they are likely to be overlooked in cat client call number searches that are limited to a specific call number type (i.e., during shelflisting). The errors in scenarios 2 and 3 above usually require correction on a record-by-record basis.

Because it is unknown how future systems will handle records that fall into the first scenario above, even though these errors also are not likely to have a negative effect on patrons using our current public catalogs, I-Share libraries are encouraged to correct their MFHD 852 field indicator values to match the actual call number type found in the 852 $h and optionally $i.  Most often, the fix will be to edit the 852 field’s first indicator value to 8, for Other. A macro is available to reset the indicator value in the MFHDs, if there are too many to be edited manually. 

Shared SQL (MFHD Records: Call Numbers category): “MFHD call no type and indicator mismatch.” This is a series of three queries. Query 1 finds all MFHDs where the CALL_NUMBER_TYPE code is set to 8, for Other. Query 2 uses the BLOB to output the 852 indicator 1 value for all records found by query 1. The output from query 3 contains holdings records where the 852 indicator 1 value is not 8, and is designed to be the query used to compare the contents of the 852 call number and indicator values for inconsistencies.

Shared macro (MFHD (Holdings Record) Maintenance section): “Addmfhd_852ind1.mex.”  This macro will change the holding record’s 852 indicator 1 to a new value, as specified by the user.  By default, the macro sets the indicator value to 8.

F14. Evaluate Notes fields in Holding records.

Many libraries add public notes to their holdings records, and consistency in the content of these notes can be important to help patrons locate materials in the library.  Non-public notes may be useful to staff for processing purposes.

(F14.A) Shared SQL (MFHD Records: General category): “Finding Public and Non-Public Notes in Holdings”.

This is a series of three queries.  Query 1 prompts for a location code, and query 2 looks up the 852 fields from the MFHDs in the specified location. The output from query 3 contains holdings records in that location that have any data in 852 $x and/or $z, so the contents of the existing notes can be reviewed.

(F14.B) Shared SQL (MFHD Records: General category): " MFHDs lacking a specific public note”.

This is a series of three queries.  Query 1 prompts for a location code, and query 2 looks up the 852 fields from the MFHDs in the specified location. Query 3 prompts for the beginning text of what should be the valid public note for that location.  The query results identify holding records in the desired location that have either no 852$z or that lack the valid note text. The 852 $x is also included in the results, in case some public notes were miscoded as $x.

Shared macro (MFHD (Holdings Record) Maintenance section):  “Addmfhd_852z.mex.”  If the fix is determined to be to add a new public note (852 $z) to the holding record, this macro can add a note with the same text to all records in the macro’s input file.

F15. Evaluate item record prices for obsolete or incorrect values. <NEW 04/2012>

In Voyager, when an item record is declared lost (either manually by library staff or based on the library’s System Administration policy on number of days overdue), the patron who borrowed the item is usually billed for a lost item replacement fee.  When the targeted item record contains an explicit amount in the Price field, that value is used for the lost item replacement fee.  However, if the item price field contains a value of zero, then the default replacement fee is determined by the library’s settings in System Administration for that item type code.  A common practice in I-Share libraries is to leave the item record’s price field set to zero to allow the replacement fee to be generated based on policy settings, but to enter an explicit price in individual item records that may be more expensive to replace than the SysAdmin default.

When libraries increase their SysAdmin default for lost item replacement fees, they may wish to reset the item record’s price value back to zero for any records where the explicit price is lower than the SysAdmin default.  In addition, libraries may wish to periodically review their item record price values to look for inconsistencies in manual data entry in that field.  For example, a simple typographical error could result in a patron being billed for thousands of dollars for a paperback book shelved in a main stacks location.

(F15.A) Shared SQL (Item Records: General category): “Item records with price not zero.”  This query looks for item records where the item price is any value other than zero.  The results are sorted from highest to lowest price.

(F15.B) Shared SQL (Item Records: General category): “Item records with price not zero and charged.”  This query looks for item records where the item price is any value other than zero, and limits the results to items that are currently charged out.  The results are sorted from highest to lowest price.  Because the query targets only charged items, the results will be smaller in number than the query above, but are more likely to be candidates for generating a replacement fee.  Staff should consider their loan periods in deciding how often to run this query.  For example, if the library’s predominant loan period is 4 weeks, this query could be run once a month to look for item prices that should be edited before a billing occurs.

Shared macro (Item Record Maintenance section): “Changeitem_price.mex.”  This macro will change the item record’s price to a new value, as specified by the user.  The default new price setting is zero.

Return to Suggested Priorities main page