Would one of you please be kind enough to save my sanity (if I have any left)?

Our cataloguers are doing a sterling job ridding our db of duplicate 001 fields, but every time they do a simple edit of *only* the 001, both OPAC and staff-admin page find TWO absolutely identical (biblio, barcode, etc) records.

Zebra incremental (-z) counts the *edit* as a completely new record.

I can get rid of it by doing a full zebra reindex (-a and -b). This "error" is totally reprodicible in our db. Can anyone elso confirm it please? (edit a 001 tag, save, wait for the CRON -z, and search on title.)

This is the way Zebra works.

A serious addition to this, is that we seem to have totally lost search capability on serials. Example: we have a series of 40 "Warship Profiles" which a mysql query (the one I gave under bug 8665) gives me:

biblionumbers:
17472, 17473, 17474, 17475, 17476, 17477, 17478, 17479, 17480, 17482, 17483, 17484, 17485, 17486, 17487, 17488, 17489, 17493, 17494, 17495, 17496, 17497, 17498, 17499, 17500, 17501, 17502, 17503, 17504, 17505, 17506, 17508, 17509, 17511, 17513, 17514, 17516, 17517, 17518, 17520

id (Control Number 001): 01032053

but NONE of the records can be found -- not by biblionumber, nor by control-number, nor by barcode, nor by title, author, etc ... The records are there (other mysql queries give me the barcodes, values, shelving locations, titles, authors, etc) but as far as staff and our patrons are concerned, they plain don't exist. Only for a mysql query.

Isn't this the problem you were trying to solve to begin with? You can access those records directly, as an aside: just go to /cgi-bin/koha/catalogue/detail.pl?biblionumber=XXXX (easiest is to just view another record, then change the biblionumber in the URL).

I have a feeling that all this is "associated with" Bug 8665, but would appreciate a little more understanding (is there a full write up somewhere? I've searched but can't find one.) I believe that 3.6 (at least .1, but changed sometime before .7) used biblionumber as the primary reference; now field 001 has become "primary." Why? There must have been a good reason, hence our efforts to normalize 001 to be a unique identifier.

No, this was a bug. There is a patch to restore biblionumber as the z:id.

Chris C. has a comment in Bug 8665 "Use a user-specified field for z:id." I am no expert with zebra (and so far haven't worked out the role or the wheareabouts of id:x), but: If z:id is currently set to '001', how do I set it to biblionumber in 3.8.5?

Perhaps this will help our non-existent "authorities"?

There's another bug, also patched, related to this. It has to do with extra spaces in a configuration file.

All suggestions would be truly appreciated -- I'll be more than happy to try and follow any suggested cures, and will obviously share the outcome here.

Regards,

Jared