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@nps.gov Library catalog: http://keys.bywatersolutions.com/ On Thu, Nov 15, 2018 at 5:56 PM Myka Kennedy Stephens < mkstephens@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)