branchcodes and case sensitivity
Hi All, We're running into a problem on 3.00.05 with the case of our branchcodes. We have configured our branches with codes like 'LO' or 'ES'. We imported all of our items against those codes, and everything looked good. School just stated, and we just began circulating, and have discovered that when items are checked in, items.holdingbranch is being populated with lowercase variants of those branchcodes ('lo' or 'es'). This causes the interface in many places to claim there's no current branch, even preventing check-out of that item. The obvious fix would be to simply set branchcode to LOWER(branchcode) in the back end, but the foreign key constraint prevents me from doing so through mysql. I'm fixing this temporarily by running UPDATEs against items setting holdingbranch=UPPER(holdingbranch), but this is a kludge. Any suggestions? -- Chris Hobbs Director, Technology New Haven Unified School District -- This message was scanned by ESVA and is believed to be clean.
Any ideas on this? On 9/3/10 1:03 PM, Chris Hobbs wrote:
Hi All,
We're running into a problem on 3.00.05 with the case of our branchcodes. We have configured our branches with codes like 'LO' or 'ES'. We imported all of our items against those codes, and everything looked good. School just stated, and we just began circulating, and have discovered that when items are checked in, items.holdingbranch is being populated with lowercase variants of those branchcodes ('lo' or 'es'). This causes the interface in many places to claim there's no current branch, even preventing check-out of that item.
The obvious fix would be to simply set branchcode to LOWER(branchcode) in the back end, but the foreign key constraint prevents me from doing so through mysql.
I'm fixing this temporarily by running UPDATEs against items setting holdingbranch=UPPER(holdingbranch), but this is a kludge.
Any suggestions?
-- Chris Hobbs Director, Technology New Haven Unified School District -- This message has been checked by ESVA and is believed to be clean.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Chris Hobbs Director, Technology New Haven Unified School District -- This message was scanned by ESVA and is believed to be clean.
Hi, On Sep 3, 2010, at 4:03 PM, Chris Hobbs wrote:
The obvious fix would be to simply set branchcode to LOWER(branchcode) in the back end, but the foreign key constraint prevents me from doing so through mysql.
A longer-term fix would be to figure out why it's not setting the branchcode correctly, but as far as cascading the update of branchcode is concerned, you could either alter the constraints to cascade updates or take advantage of MySQL's ability to disable foreign key checks temporarily: SET FOREIGN_KEY_CHECKS = 0; update branches set branchcode = lower(branchcode); -- update tables that reference to branchcode SET FOREIGN_KEY_CHECKS = 1; Obviously something like this would call for doing a full backup first. Regards, Galen -- Galen Charlton VP, Data Services Equinox Software, Inc. / Your Library's Guide to Open Source email: gmc@esilibrary.com direct: +1 352-215-7548 skype: gmcharlt web: http://www.esilibrary.com/
We're running 3.2 We just did a bulk MARC import of 1431 records. There are a few problems with the call numbers in the staff interface. We use our own call number system, so the information is in 099$a, but we've also copied it to 942$h and 952$o (because I wasn't sure about how / where it would display). Problem 1) I wanted the call numbers at the top of the ISBD view so the following is the first line of the ISBD. #099|<br/><br/><label>Call No.: </label>|{ 099a }| followed by #100|<br/><br/>|{ 100a }{ 100b } . . . etc. I thought this would provide a line break between the display of the 099 and the 100, and it did, briefly, but now it's lumping the two fields into one line again. Problem 2) The call number does not display in the normal view. It should appear in the holdings tab. The information is there in the record. I accidentally discovered that if I edit the item record (and not actually touch anything) and then save it, the call number appears. This first batch of records is only a small sample of our import. There must be a better way than looking at every item record. Elaine Bradtke
Hi,
On Sep 3, 2010, at 4:03 PM, Chris Hobbs wrote:
The obvious fix would be to simply set branchcode to LOWER(branchcode) in the back end, but the foreign key constraint prevents me from doing so through mysql. A longer-term fix would be to figure out why it's not setting the branchcode correctly, but as far as cascading the update of branchcode is concerned, you could either alter the constraints to cascade updates or take advantage of MySQL's ability to disable foreign key checks temporarily:
SET FOREIGN_KEY_CHECKS = 0; Galen's direction on removing the foreign key checks temporarily got me
On 9/15/10 9:01 AM, Galen Charlton wrote: the ability to update branchcodes across all of my db tables, but I seem to have a problem with my zebra indexes - most of my items (those that have not been circulated since the conversion) do not have branch information visible information - here's a screen shot: http://www.nhusd.k12.ca.us/it/files/images/Screen%20shot%202010-09-23%20at%2... I have tried re-indexing in the hopes that it would work itself out (rebuild_zebra.pl -b -a -r) but no luck. Any idea how to get the correct (lowercase) branch info into the zebra indexes? Thanks, -- Chris Hobbs Director, Technology New Haven Unified School District -- This message was scanned by ESVA and is believed to be clean.
2010/9/24 Chris Hobbs <chobbs@nhusd.k12.ca.us>:
On 9/15/10 9:01 AM, Galen Charlton wrote:
Hi,
On Sep 3, 2010, at 4:03 PM, Chris Hobbs wrote:
The obvious fix would be to simply set branchcode to LOWER(branchcode) in the back end, but the foreign key constraint prevents me from doing so through mysql.
A longer-term fix would be to figure out why it's not setting the branchcode correctly, but as far as cascading the update of branchcode is concerned, you could either alter the constraints to cascade updates or take advantage of MySQL's ability to disable foreign key checks temporarily:
SET FOREIGN_KEY_CHECKS = 0;
Galen's direction on removing the foreign key checks temporarily got me the ability to update branchcodes across all of my db tables, but I seem to have a problem with my zebra indexes - most of my items (those that have not been circulated since the conversion) do not have branch information visible information - here's a screen shot: http://www.nhusd.k12.ca.us/it/files/images/Screen%20shot%202010-09-23%20at%2...
I have tried re-indexing in the hopes that it would work itself out (rebuild_zebra.pl -b -a -r) but no luck. Any idea how to get the correct (lowercase) branch info into the zebra indexes?
Indeed, in misc/maintenance/ there is a script sync_items_in_marc_bib.pl That will sync up what is in the MARC (which zebra uses for its indexes) with what is in the items table. The nice thing is, it puts an entry into the zebraqueue table, and so the cron job indexes the changed ones. Chris
participants (4)
-
Chris Cormack -
Chris Hobbs -
Elaine Bradtke -
Galen Charlton