Skip to main content
ExLibris
  • Subscribe by RSS
  • ExLibris Dev

    Duplicate Order Numbers

    • Article Type: General
    • Product: Aleph
    • Product Version: 20, 21, 22, 23

    Description:
    There are cases where the exact same order number appears on two different order records.

    In one case this happened when an order was moved from one bib to another and then an order was created on the original bib. In the other case it happened during creation of orders using file-90.

    Resolution:

    Since the z68_order_number column is defined as NONUNIQUE, there is nothing at the Oracle level to prevent such duplication.

     

    As noted in the z68.pdf document:

    In the Acquisitions/Serials module the number is added automatically from the “last-order-number” counter (UTIL G/2). The user is free to change the number, as long as the number is not already in use.

     

    If the staff user tries to change the number to one already in use, the message "Duplicate order number" appears and prevents such an update.

     

    But if the user manually enters a number which is higher than the current “last-order-number” value and the system increments the counter and then later arrives at the existing number, it can and *will* go ahead and create a record with the same z68_order_number.   

    (Note that there’s a  “setenv  unique_order_number_2 “ value in aleph_start which can force the z68_order_number_2 to be UNIQUE.) 

     

    Also when orders are created by file-90 there is no check whether an order number which will be assigned is already in the system and a duplicate order number might be produced.

     

    How to handle existing cases?  This is no problem as far as the system is concerned:  though the z68_order_number is defined as NONUNIQUE, the z68_rec_key is UNIQUE.  If the orders with duplicate z68_order_numbers are closed, there is certainly no problem.  But there could be some confusion when the user searches on the Order number.  

     

    How to prevent z68_order_number duplication?   Avoid manually updating the order-number field to a value with which the “last-order-number” counter could potentially collide.  Another possibility is -- once duplicates have been eliminated -- to change the ./alephm/sql_tab/z68_create_index_1.sql and ./z68_rebuild_index_1.sql from:  "CREATE INDEX ..." to "CREATE UNIQUE INDEX ..." and do util a/17/3 for z68_id1 to rebuild it.

     

     


    • Article last edited: 01/25/2016
    •  
    •  
    //doorbell.io feedback widged