[Koha] [EXTERNAL] Filtering inventory results by cn_sort vs. callnumber

[Hernandez, Heather]

Hi!

Thank you, Myka, for that report to see if cn_sort does sort LC call
numbers with colons in the cutters correctly!  Unfortunately, it doesn't.
The following not come across clearly, but here are some results from
running that report in our catalog on the G class schedule--if anyone would
like to see this live, let me know & I'll make the report/output public in
our OPAC:

192284 G4363 V4 A1 1921 G46 1928 G4363 V4 A1 01921 G00046 01928 lcc
G4364 S5:2 C45 1885 F3a G4364 S00005:00002 C00045 018 lcc
158187 G4364 S5:2 P7 E635 1980 H5 G4364 S00005:00002 P00007 E00635 01980
H00005 lcc
183574 G4364 S5:2 S68 E15 1980 A44 G4364 S00005:00002 S00068 E00015 01980
A00044 lcc
183572 G4364 S5:2 S68 E15 1980 A44 G4364 S00005:00002 S00068 E00015 01980
A00044 lcc
100334 G4364 S5:2 W33 1922 C34 G4364 S00005:00002 W00033 01922 C00034 lcc
100020 G4364 S5:2 W33 1922 C34 G4364 S00005:00002 W00033 01922 C00034 lcc
G4364 S5:2 W33 1922 C34a G4364 S00005:00002 W00033 01922 C00034A lcc
191312 G4364 S5:2 W33 H36 G4364 S00005:00002 W00033 H00036 lcc
100125 G4364 S5:2 W36 1915 P36 G4364 S00005:00002 W00036 01915 P00036 lcc
G4364 S5:2 W36 1915 P36a G4364 S00005:00002 W00036 01915 P00036A lcc
189915 G4364 D22 P54 1889 U8 1890 G4364 D22 P54 01889 U00008 01890 lcc
191315 G4364 E9 1965 E97 G4364 E9 01965 E00097 lcc
192172 G4364 L663 P5 1889 U8 G4364 L663 P5 01889 U00008 lcc
G4364 L663 P5 1889 U8 G4364 L663 P5 01889 U00008 lcc
106731 G4364 O2 1939 B45 G4364 O2 01939 B00045 lcc
100023 G4364 P2 A1 1899 U5 1979 G4364 P2 A1 01899 U00005 01979 lcc
170703 G4364 P7 A3 1880 E45 1977 G4364 P7 A3 01880 E00045 01977 lcc

All the call numbers with the cutter "S5:2" are filing before cutters in
the rest of the alphabet, where they should be filing after "S5," and
certainly after all the call numbers after them in the above example.

So for the purposes of the bug under discussion, it's probably great to use
cn_sort!  But if any collection that uses LC classification has
cartographic materials (maps, charts, etc.) cataloged in these G areas &
follows LC practice of the cutters with colons in them, the fact that they
don't sort correctly is something to be aware of.  A bug about it has been
created, Bug 17269
<https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17269>, but
there's been no activity on it.

This report is also really useful for spotting formatting errors in call
numbers!  If there were any.  I'm not admitting anything.:):):)

Cheerio!
h2
~~~~~~~~~~~~~~
Heather Hernandez
Technical Services Librarian
San Francisco Maritime National Historical Park Research Center
2 Marina Blvd., Bldg. E, 3rd floor, San Francisco, CA  94123-1284
415-561-7032, heather_hernandez at nps.gov
Library catalog: http://keys.bywatersolutions.com/


On Thu, Nov 15, 2018 at 5:56 PM Myka Kennedy Stephens <
mkstephens at lancasterseminary.edu> wrote:

> To Heather: I'm the one who reported and signed off on Bug 21629.
> Unfortunately, I did not test it with any LC numbers with colons in them.
> We don't have any items in our catalog with those types of numbers, so
> that's not been an issue that's affected us. An easy way to check and see
> if cn_sort does correctly sort those types of call numbers would be to
> write a simple shelf list report. Here's an example that someone at ByWater
> wrote for us a few years ago to test the reliability of cn_sort:
>
> select barcode, itemcallnumber,cn_sort, cn_source from items where
> itemcallnumber like "B%" order by cn_sort
>
> You could change "B%" to "G%" for it to return a list of everything in your
> catalog from the G class.
>


> (snip)
>