p_item_05 returning results in ASCII/decimal order instead of correct LC order
- Article Type: General
- Product: Aleph
- Product Version: 16.02
Description:
One of our libraries requested a item-05 shelf list report with the following parameters:
Call No. Range: A - AG
Call No. Type: 0 (LC)
Call No. Location: 1st
Sub-Library:ABC
Collection: ABCA
Item Status: 01 (books)
Output File: abca_01_a_ag
The log file is $alephe_scratch/abc50_p_item_05.12486. When viewing the report the items are not ordered correctly. The order of the class number (the first part of an LC call number) is as follows:
AC1
AC149
AC15
AC20
AC25
AC30
AC35
AC5
AC55
AC6
AC60
AC7
AC75
AC8
AE1
AE2
AE25
AE27
AE35
AE5
AE55
AE61
AE65
This is the order one would expect from a range of Dewey Decimal call numbers. The LOG file shows that it loaded the following file:
/exlibris/aleph/u16_1/abc50/tab/tab_filing_call_no
The 0 (zero) group (LC) is set correctly.
Why is the order of the items incorrect? If I do the following SQL statement against ABC50's Z30 table, the items are ordered correctly:
....
All items returned by this SQL statement *do* have a Z30-CALL-NO-KEY.
Resolution:
I found that abca_01_a_ag print file/output file was sorted correctly. The site was doing a Print-preview in the Task Manager which invoked the ./form_eng/shelf-list.xsl, which had been modified locally to include a "sort select" line.
I found that
/exlibris/aleph/a16_1/usm01/form_eng/shelf-list.xsl on our v16 server and the as-distributed
/exlibris/aleph/a16_1/usm01/form_eng/shelf-list.xsl on *your* server do *NOT* contain this line:
xsl:sort select="./call-no"/
It seems that this was something which was added locally.
- Article last edited: 10/8/2013