Hello! I am using Koha 3.0 with Marc21 and Nozebra. I had a very similar error in OPAC search: "Can't call method "as_usmarc" on an undefined value at /usr/share/koha/lib/C4/Search.pm line ..." Rebuilding nozebra index helped - at least now searching is going fine - but could anyone help me with following: 1. Shall I permanently rebuild nozebra index via cronjob? If no, why the index was corrupted and how could I control this in future? 2. As far as I know, NoZebraIndexes value controls, what goes to MYSQL table, can I modify the value? I.e. change MARC subfields to be extracted to index? I guess, I have to modify "rebuild_nozebra.pl" file appropriately? Anything else to be modifies in this case? Thanks in Advance Irakli Irakli Garibashvili Director Georgian National Scientific Library Address: M. Aleksidse str.1-4, Tbilisi, 0193 Georgia From: Rachel Hollis Sent: Wednesday, November 03, 2010 8:43 PM To: Geovana de Paula Santos Tarricone ; koha@lists.katipo.co.nz Subject: Re: [Koha] Can't call method "as_usmarc" on an undefined value at /usr/share/koha/lib/C4/Search.pm line 2388. Greetings, I understand that rebuilding Zebra (or noZebra) is useful. It's been suggested that these be run: /your/path/to/rebuild_zebra.pl -v -b -r -s /your/path/to/rebuild_zebra.pl -d /tmp It's also recommended to set up Zebra rebuild on a cron job. We're still seeing the error when searching the catalog. For instance, searches for "resumes" and "jobs" result in the error but "640.14" (the Dewey call number for resumes and jobs) searches show the materials. Searching "maps" has the error but "map" does not. Searching "medical" does also but not "medical dictionary." I read somewhere that the error may have something to do with an incompatibility with Marc favors in the database. I also read that it may be an issue with biblios in Zebra that no longer exist in Koha. We have reverted imports and re-cataloged biblios as well as deleted items and records; this scenario fits. We have Zebra set up on cron as: /rebuild_zebra.pl -a -z /rebuild_zebra.pl -b -z However we use noZebra and I'm a librarian worried about the damage I might cause while on a command line. Rachel Hollis, librarian Stevens-Henager College, Boise Idaho Campus 2010 Winner of Best Places to Work in Idaho From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Geovana de Paula Santos Tarricone Sent: Thursday, October 28, 2010 5:55 AM To: koha@lists.katipo.co.nz Subject: [Koha] Can't call method "as_usmarc" on an undefined value at /usr/share/koha/lib/C4/Search.pm line 2388. Hi! Could someone help me? After I had cataloged my books, I did a search, on Intranet. Koha showed me a list with all my cataloged itens. When I clicked on page 2 of the list, I had the error: Can't call method "as_usmarc" on an undefined value at /usr/share/koha/lib/C4/Search.pm line 2388. I'm using Koha 3.00.06 and I googled it and this problem occurs on: http://library.gretsauniversity.ac.ke/cgi-bin/koha/opac-search.pl?q=au:Hill%... , but in OPAC. What should I do to fix it? Thanks in advance, Geovana. This message is for the designated recipient only and may contain privileged, proprietary, or otherwise private information. If you have received it in error, please notify the sender immediately and delete the original. Any other use of the email by you is prohibited. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

Le 11/01/2011 10:42, Irakli Garibashvili a écrit :

Hi! Hi Irakli, welcome on the list. Happy New Year. If I remember correctly, we met in Yerevan some years ago.

We are using Koha 3.0 (Marc21, Nozebra) and it looks like fields for items have some problems with Georgian script:

I thought that you would be in UNIMARC rather than MARC21. My illusions about the use of UNIMARC outside France took a bad stroke :D

I am not sure what is the reason for this problem but

data entry (in Georgian script - in UTF-8) for the fields like CallNumb, copynumber, (notes??),.. in some cases result in corrupted text.

It is hard to know precisely, problem could be that your biblio record doesnot have a correct leader. All leaders should have "a" for position 9. So that it is double encoded by MARC::Record when decoded. And I also guess that somehow encoding is better handled in 3.2 (with some data normalization) My 2 cents.

I have found that some records in nozebra index and XML also contain similar corrupted texts.

I am not quite sure how to explain what exactly is corrupted in this text, but it looks like I see each bit of UTF-8 separately, which must be an indication, that character conversion goes wrong for these fields/tables.

I have checked MySQL structure - all appropriate fields have UTF8_general collation... (so this must be correct)

Problem with perl codes? Where?

Could someone help me?

Thanks in advance, Irakli

-- Henri-Damien LAURENT BibLibre