This will be a slightly more technical answer that may require some direct database access to ascertain more details.
You mention that the call numbers are identified as DDC. So that's label_class of 2, I believe. We are using Dewey (DDC) for all of our materials by default as well in our consortium. I'd be curious to know what the label_sortkey values were for those call numbers you mention. That field is what actually drives the sorting values for a given set. For example, just pulling a few samples from our asset.call_number table: label -> label_sortkey 720 Mag -> 720_000000000000000_MAG 720.9 How -> 720_900000000000000_HOW 720.92 Ros -> 720_920000000000000_ROS 720.973 THO -> 720_973000000000000_THO So, the normalizer for Dewey class ought to pad in the extra zeroes with the first . decimal point to set the initial sorting. In that case, I would expect 720 by itself to be 720_000... and 720.1 to be 720_100.... in the sorting, which would result in the expected order. But perhaps something is not quite right with your call number's label_sortkey values, or it's behaving in yet another unexpected way. I do not know how your system is setup, but it's possible for the label_sortkey values to be incorrect due to bugs or earlier implementations of Dewey normalizers in previous run versions of Evergreen. This has happened to us before, where the class was set appropriately, but we had to run all the call numbers back through to update the label_sortkey appropriately. Hope this gets you somewhere to start looking, please feel free to follow up with further questions. -- Ben On Thu, Apr 24, 2014 at 3:32 PM, Adam Shire <[email protected]> wrote: > Hi Everyone, > > We are testing in evergreen 2.5.2 > > I'm noticing what I think looks like incorrect behavior when using the > call number browse feature. > > Doing a call number browse search for 720 results in the following call > number sort order: > > 720 H47 1979 > 720 .H47 > 720.1 H74 1979 > 720.1 .H47 1980 > 720.1 .H74 1979 > 720 H74 1979 > 720 .H74 1979 > > > It looks like the decimal point might be throwing things off. I think that > should be taken care of in a normalizer, but maybe there is a reason not > to. I think the 720.1's should come at the end of this list, regardless of > the decimal point before the cutter. > > All of the call numbers are identified as DDC. > > you can probably replicate this here > http://emerson.eg.flo.org/eg/opac/cnbrowse?cn=715&locg=2 > > > I didn't see any bug reports that seemed to address this specific issue, > so I'm wondering if there could be something else causing this behavior. > > thanks, > Adam > > -- > > Adam Shire > Member Services Librarian > Fenway Libraries Online <http://flo.org> > 617-442-2384 > -- Benjamin Shum Evergreen Systems Manager Bibliomation, Inc. 24 Wooster Ave. Waterbury, CT 06708 203-577-4070, ext. 113
