Cannot edit record if indexing fails?
Hi there ! I need help with a problem I'm trying to figure out testing koha (3.000.1 stable). Followed all the steps recommended for working with UTF-8 The scenario goes like this: We have 13 and some libraries that we want to manage with Koha. Right now I'm testing the import tools (web based and command line) with records from one of those databases (around 50.000 records). The two tools work fine and get the work done, but when the records are more than 5000 the web based interface takes too long and sometimes it never ends... One problem arises when I rebuild the zebra index. The process rejects some records (I don't know how many). AFAIK, in this records, the script chokes on 952 records that have a Ü (capitalized U with a dieresis) or a Ö (capitalized O with a dieresis) character on the shelving location subfield (I send some images as attachment). The problem is not with every ü character. in fact, if they are present i.e. in the author field and not in the 952 field, they pass to the index and I can find them without any problem. The thing that makes things more dificult is that... even if I wanted to fix this records by hand with Koha cataloging interface... I can't, because I can't search for them (I can search for them, but I can't find or retrieve them, because they weren't indexed)... So ... I can "fix" (they are correct, I shouldn't need to fix them, but I could change the conflictive characters where needed) those records in the original database and bulkmarcimport them deleting everything (-d option). That would be a nice solution for the first database ... but there are 13 of them ... and I don't want to be erasing 'n-1' databases when I hit a similar problem importing the database number 'n'... So ... anyone can give some advice on how to solve this? is there a way to find/edit records without having to search for them? or .. better .. is there a way to patch/fix the indexing process, so those characters can pass without problem? Thanks in advance -- Ing. J. Martin Longo Depto. Gestion Informatica SID - UNCuyo http://sid.uncu.edu.ar
En su momento, Martin Longo escribió:
Hi there !
I need help with a problem I'm trying to figure out testing koha (3.000.1 stable). Followed all the steps recommended for working with UTF-8
The scenario goes like this:
We have 13 and some libraries that we want to manage with Koha. Right now I'm testing the import tools (web based and command line) with records from one of those databases (around 50.000 records). The two tools work fine and get the work done, but when the records are more than 5000 the web based interface takes too long and sometimes it never ends...
One problem arises when I rebuild the zebra index. The process rejects some records (I don't know how many). AFAIK, in this records, the script chokes on 952 records that have a Ü (capitalized U with a dieresis) or a Ö (capitalized O with a dieresis) character on the shelving location subfield (I send some images as attachment). The problem is not with every ü character. in fact, if they are present i.e. in the author field and not in the 952 field, they pass to the index and I can find them without any problem.
The thing that makes things more dificult is that... even if I wanted to fix this records by hand with Koha cataloging interface... I can't, because I can't search for them (I can search for them, but I can't find or retrieve them, because they weren't indexed)...
So ... I can "fix" (they are correct, I shouldn't need to fix them, but I could change the conflictive characters where needed) those records in the original database and bulkmarcimport them deleting everything (-d option). That would be a nice solution for the first database ... but there are 13 of them ... and I don't want to be erasing 'n-1' databases when I hit a similar problem importing the database number 'n'...
So ... anyone can give some advice on how to solve this? is there a way to find/edit records without having to search for them? or .. better .. is there a way to patch/fix the indexing process, so those characters can pass without problem?
Thanks in advance
Sorry .. I forgot to attach the images ... -- Ing. J. Martin Longo Depto. Gestion Informatica SID - UNCuyo http://sid.uncu.edu.ar
There are two ways to get around the not being able to search issue. #1 someone is working on a patch to include a link to the imported record from the imported screen. #2 Make note of the bib number that was assigned when the item was added (I think it shows somewhere) and then you can just put that in the URL next to biblionumber= Hope that helps - and I hope the patch is available soon :) --- Nicole C. Engard Open Source Evangelist, LibLime (888) Koha ILS (564-2457) ext. 714 nce@liblime.com AIM/Y!/Skype: nengard http://liblime.com http://blogs.liblime.com/open-sesame/ 2009/4/4 Martin Longo <jmlongo@uncu.edu.ar>:
En su momento, Martin Longo escribió:
Hi there !
I need help with a problem I'm trying to figure out testing koha (3.000.1 stable). Followed all the steps recommended for working with UTF-8
The scenario goes like this:
We have 13 and some libraries that we want to manage with Koha. Right now I'm testing the import tools (web based and command line) with records from one of those databases (around 50.000 records). The two tools work fine and get the work done, but when the records are more than 5000 the web based interface takes too long and sometimes it never ends...
One problem arises when I rebuild the zebra index. The process rejects some records (I don't know how many). AFAIK, in this records, the script chokes on 952 records that have a Ü (capitalized U with a dieresis) or a Ö (capitalized O with a dieresis) character on the shelving location subfield (I send some images as attachment). The problem is not with every ü character. in fact, if they are present i.e. in the author field and not in the 952 field, they pass to the index and I can find them without any problem.
The thing that makes things more dificult is that... even if I wanted to fix this records by hand with Koha cataloging interface... I can't, because I can't search for them (I can search for them, but I can't find or retrieve them, because they weren't indexed)...
So ... I can "fix" (they are correct, I shouldn't need to fix them, but I could change the conflictive characters where needed) those records in the original database and bulkmarcimport them deleting everything (-d option). That would be a nice solution for the first database ... but there are 13 of them ... and I don't want to be erasing 'n-1' databases when I hit a similar problem importing the database number 'n'...
So ... anyone can give some advice on how to solve this? is there a way to find/edit records without having to search for them? or .. better .. is there a way to patch/fix the indexing process, so those characters can pass without problem? Thanks in advance
Sorry .. I forgot to attach the images ...
-- Ing. J. Martin Longo Depto. Gestion Informatica SID - UNCuyo http://sid.uncu.edu.ar
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi Martin Martin Longo schrieb:
One problem arises when I rebuild the zebra index. The process rejects some records (I don't know how many). AFAIK, in this records, the script chokes on 952 records that have a Ü (capitalized U with a dieresis) or a Ö (capitalized O with a dieresis) character on the shelving location subfield (I send some images as attachment). The problem is not with every ü character. in fact, if they are present i.e. in the author field and not in the 952 field, they pass to the index and I can find them without any problem.
Koha doesn't like Call numbers with non-ascii-characters. I don't know why ...
The thing that makes things more dificult is that... even if I wanted to fix this records by hand with Koha cataloging interface... I can't, because I can't search for them (I can search for them, but I can't find or retrieve them, because they weren't indexed)...
If I remember well the time I was dealing with this problem I had to work on the mysql-database itself. I think this is clearly a bug to be reported. Beda
participants (3)
-
Beda Szukics -
Martin Longo -
Nicole Engard