On Thu 15 Apr, I wrote:
[snip] Clicking on the title produced a partial display of the Marc entries:
020 -INTERNATIONAL STANDARD BOOK NUMBER a International Standard Book Number 0406948291
852 -LOCATION/CALL NUMBER k Call number prefix (NR) TB
[snip] [followed by a box containing]
homebranch RH
"TB" stands for text book so the 852 line would seem to be wrong. (If I go to edit I am given a drop down box for that line with text book, law report etc.)
Further experiment shows that the error in the 852(k) line is *introduced* by the Item Type Admin page (admin/itemtypes.pl ). Yesterday I got the daemon to work at least partially and it found the biblio for the Perl Cookbook at the Library of Congress and added it. But the 852k line was still TB (ie text book). So I added another "type", BS (for brussells sprout --- not I admit something usually found in libraries) and searched for the Cookbook again. When I tried to edit it (aqui.simple/addbiblio.pl ) the 852 line contained text book and the drop down menu now included the item brussells sprout. And that expression appears in table itemtypes. But seeing how TB gets into the display is way beyond me. A couple of tables show the Perl Cookbook: select biblionumber,author,title from biblio; +--------------+--------------------+----------------------------------------+ | biblionumber | author | title | +--------------+--------------------+----------------------------------------+ | 1 | Gammie | Tolley Yellow Tax Handbook | | 2 | Michael Thomas | Stamp Duty Land Tax | | 3 | Longrigg Higgins | Family Breakdown and Trusts | | 4 | DuBois, Paul, | MySQL Cookbook / | | 5 | Petersen, Theo. | Web development with Apache and Perl / | | 6 | Christiansen, Tom. | Perl cookbook / | +--------------+--------------------+----------------------------------------+ 6 rows in set (0.00 sec) mysql> select biblionumber,itemtype,isbn from biblioitems; +------------------+----------+------------+ | biblionumber | itemtype | isbn | +--------------+----------+------------+ | 1 | NULL | 0406939985 | | 2 | TB | 0521545153 | | 3 | TB | 0406948291 | | 4 | NULL | 0596001452 | | 5 | NULL | 1930110065 | | 6 | NULL | 1565922433 | +------------------+----------+------------+ 6 rows in set (0.00 sec) The 852 line still shows as TB although the itemtype line in the table is NULL. It has somehow found its way into marc_subfield_table: select subfieldid,bibid,tag,subfieldcode,subfieldvalue from marc_subfield__table where bibid='6'; +------------+-------+-----+--------------+------------------------+ | subfieldid | bibid | tag | subfieldcode | subfieldvalue | +------------+-------+-----+----+----------------------------------+ | 89 | 6 | 010 | a | 99176053 | | 90 | 6 | 020 | a | 1565922433 | | 91 | 6 | 035 | a | (DLC) 99176053 | | 92 | 6 | 035 | a | (OCoLC)39872119 | | 93 | 6 | 852 | k | TB | | 94 | 6 | 100 | a | Christiansen, Tom. | | 95 | 6 | 245 | a | Perl cookbook / | | 96 | 6 | 260 | c | c1998. | | 97 | 6 | 300 | a | xxxiv, 757 p. ; | | 98 | 6 | 300 | c | 24 cm. | | 99 | 6 | 650 | a | Perl (Computer program language) | | 100 | 6 | 650 | a | Perl (Computer program language) | | 101 | 6 | 090 | c | 6 | | 102 | 6 | 090 | d | 6 | | 103 | 6 | 952 | b | RH | | 104 | 6 | 952 | d | RH | | 105 | 6 | 952 | u | 5 | +------------+-------+-----+--------------+------------------------+ 17 rows in set (0.00 sec) Have 852 and 952 got mixed up somewhere? (RH, ie Roger Horne, is what I would have expected to see in "location" on a search.) But it turns out to be more complicated ... On a simple search the location of the Perl Cookbook shows correctly as Roger Horne (although it doesn't in a Marc search). But the location of the Mysql Cookbook doesn't show as Roger Horne in a simple search but as a blank (but shows as TB in a full search). There are very small differences in the marc_subfield_table but nothing that would appear to cause this: +------------+-------+-----+--------------+----------------------------------------+ | subfieldid | bibid | tag | subfieldcode | subfieldvalue | +------------+-------+-----+--------------+----------------------------------------+ | 69 | 5 | 010 | a | 2002281940 | | 70 | 5 | 020 | a | 1930110065 | | 71 | 5 | 035 | a | (OCoLC)ocm49871541 | | 72 | 5 | 852 | k | TB | | 73 | 5 | 100 | a | Petersen, Theo. | | 74 | 5 | 245 | a | Web development with Apache and Perl / | | 75 | 5 | 260 | c | c2002. | | 76 | 5 | 300 | a | xviii, 410 p. : | | 77 | 5 | 300 | b | ill. ; | | 78 | 5 | 300 | c | 24 cm. | | 79 | 5 | 650 | a | Perl (Computer program language) | | 80 | 5 | 650 | a | Web site development. | | 81 | 5 | 650 | a | Open source software. | | 82 | 5 | 650 | a | Open source software. | | 83 | 5 | 090 | c | 5 | | 84 | 5 | 090 | d | 5 | | 85 | 5 | 952 | u | 3 | | 86 | 5 | 952 | b | RH | | 87 | 5 | 952 | d | RH | | 88 | 5 | 952 | u | 4 | Roger -- Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB mailto:roger@number7.demon.co.uk
On 2004-04-17 19:07:37 +0100 Roger Horne <roger@hrothgar.co.uk> wrote:
Further experiment shows that the error in the 852(k) line is *introduced* by the Item Type Admin page (admin/itemtypes.pl ). [...]
The code for admin/itemtypes.pl shows it's working on the itemtypes table. I don't think this touches MARC at all.
But seeing how TB gets into the display is way beyond me. [...]
The code for that starts around acqui.simple/addbiblio.pl line 125.
The 852 line still shows as TB although the itemtype line in the table is NULL. It has somehow found its way into marc_subfield_table: [...]
I think the undocumented function MARChtml2marc is doing that, starting at C4/Biblio.pm:810, based on the koha-MARC mappings set in the Parameters interface. Maybe another developer can tell us for sure. I hope the above helps you to track down the problem. -- MJR/slef My Opinion Only and possibly not of any group I know. Please http://remember.to/edit_messages on lists to be sure I read http://mjr.towers.org.uk/ gopher://g.towers.org.uk/ slef@jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/
On Mon 19 Apr, MJ Ray wrote:
I hope the above helps you to track down the problem.
I will try. I have a more immediate problem... While playing around, I changed from budget based to simple acquisitions and I deleted the all "types" (eg law report). I then added a new z* server and used the z* daemon to try to find another book. It found it and I went through the usual steps of saving etc. However when I searched for it it was nowhere to be found. It seems that some of the tables of the db had got corrupted: what in some showed two books as 16 and 17 others showed them as 15 and 16. I think it is extrememly unlikely that I could replicate this ... It is far from being a disaster: I only had about 16 books in the db, and quite a few of those were entered simply to try out the daemon on unusual titles. My question is simple: is there a simple way to delete all the bibliographic data so that I can start again (without deleting the database itself and re-installing Koha from scratch)? Roger -- Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB http://hrothgar.co.uk/ mailto:roger@hrothgar.co.uk
Roger Horne a écrit :
On Mon 19 Apr, MJ Ray wrote:
I hope the above helps you to track down the problem.
I will try. I have a more immediate problem...
While playing around, I changed from budget based to simple acquisitions and I deleted the all "types" (eg law report). I then added a new z* server and used the z* daemon to try to find another book. It found it and I went through the usual steps of saving etc. However when I searched for it it was nowhere to be found. It seems that some of the tables of the db had got corrupted: what in some showed two books as 16 and 17 others showed them as 15 and 16. I think it is extrememly unlikely that I could replicate this ...
It is far from being a disaster: I only had about 16 books in the db, and quite a few of those were entered simply to try out the daemon on unusual titles.
yes, but it's strange anyway...
My question is simple: is there a simple way to delete all the bibliographic data so that I can start again (without deleting the database itself and re-installing Koha from scratch)?
scripts/misc/bulkmarcimport.pl has an option to delete every biblio-related informations (don't forget to EXPORT PERL5LIB=/path/to/koha before ./bulkmarcimport.pl) -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)
On Mon 19 Apr, paul POULAIN wrote:
scripts/misc/bulkmarcimport.pl has an option to delete every=20 biblio-related informations (don't forget to EXPORT=20 PERL5LIB=3D/path/to/koha before ./bulkmarcimport.pl)
Thanks. Roger -- Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB http://hrothgar.co.uk/ mailto:roger@hrothgar.co.uk
Hi all, The NPL tech team met on Monday and one of the items on our agenda is getting our Bookmobile (a library branch on weels) Koha-enabled. As things stand right now all transactions are still hand-written. The Bookmobile regularly travels to locations where no internet connection is available and so a dedicated wireless link is not feasable at this time. Does anyone have a similar problem (and hopefully a solution) or any ideas for automating the Bookmobile with Koha? One idea we had was installing a full version of Koha on a laptop that the Bookmobile staff would carry with them throughout the day to use for transactions...at the end of the day the Bookmobile transactions would be merged into the system-wide Koha database and the laptop's database would also be updated with the rest of the transactions, etc. Any comments, suggestions? Thanks, -- Joshua Ferraro Systems Administrator Nelsonville Public Library System
This idea is also required for branches without a dedicated internet link. For instance, the Theosophical society. Most branches don't even have a telephone, let alone internet. So.. what needs to happen..... i take koha's daily transactions to a net cafe or something, and upload that file to a main internet connected server, or a email address who can go to the central koha computer, and process the file. Then, that person creates diff files for all the branches... excluding their own transactions they put in. the other branch librarians copy the diff file to a disk, and give koha it, and it processes it, modifying the database accordingly. One idea. Lets get off the biblionum, biblioitem and biblioitemnum system, and have Barcodes as our keys. Just an idea. Waylon At 01:06 22/04/04, Joshua Ferraro wrote:
Hi all,
One idea we had was installing a full version of Koha on a laptop that the Bookmobile staff would carry with them throughout the day to use for transactions...at the end of the day the Bookmobile transactions would be merged into the system-wide Koha database and the laptop's database would also be updated with the rest of the transactions, etc.
--- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.554 / Virus Database: 346 - Release Date: 20/12/03
Roger, from your example, it looks like the only thing you have in the 852 tag is the itemtype, in 852k. At the risk of looking stupid, may I ask if you have mapped 852k to biblioitems.itemtype? Stephen Roger Horne said:
On Thu 15 Apr, I wrote:
[snip] Clicking on the title produced a partial display of the Marc entries:
020 -INTERNATIONAL STANDARD BOOK NUMBER a International Standard Book Number 0406948291
852 -LOCATION/CALL NUMBER k Call number prefix (NR) TB
[snip] [followed by a box containing]
homebranch RH
"TB" stands for text book so the 852 line would seem to be wrong. (If I go to edit I am given a drop down box for that line with text book, law report etc.)
Further experiment shows that the error in the 852(k) line is *introduced* by the Item Type Admin page (admin/itemtypes.pl ). Yesterday I got the daemon to work at least partially and it found the biblio for the Perl Cookbook at the Library of Congress and added it. But the 852k line was still TB (ie text book). So I added another "type", BS (for brussells sprout --- not I admit something usually found in libraries) and searched for the Cookbook again. When I tried to edit it (aqui.simple/addbiblio.pl ) the 852 line contained text book and the drop down menu now included the item brussells sprout. And that expression appears in table itemtypes.
But seeing how TB gets into the display is way beyond me. A couple of tables show the Perl Cookbook:
select biblionumber,author,title from biblio; +--------------+--------------------+----------------------------------------+ | biblionumber | author | title | +--------------+--------------------+----------------------------------------+ | 1 | Gammie | Tolley Yellow Tax Handbook | | 2 | Michael Thomas | Stamp Duty Land Tax | | 3 | Longrigg Higgins | Family Breakdown and Trusts | | 4 | DuBois, Paul, | MySQL Cookbook / | | 5 | Petersen, Theo. | Web development with Apache and Perl / | | 6 | Christiansen, Tom. | Perl cookbook / | +--------------+--------------------+----------------------------------------+ 6 rows in set (0.00 sec)
mysql> select biblionumber,itemtype,isbn from biblioitems; +------------------+----------+------------+ | biblionumber | itemtype | isbn | +--------------+----------+------------+ | 1 | NULL | 0406939985 | | 2 | TB | 0521545153 | | 3 | TB | 0406948291 | | 4 | NULL | 0596001452 | | 5 | NULL | 1930110065 | | 6 | NULL | 1565922433 | +------------------+----------+------------+ 6 rows in set (0.00 sec)
The 852 line still shows as TB although the itemtype line in the table is NULL. It has somehow found its way into marc_subfield_table:
select subfieldid,bibid,tag,subfieldcode,subfieldvalue from marc_subfield__table where bibid='6'; +------------+-------+-----+--------------+------------------------+ | subfieldid | bibid | tag | subfieldcode | subfieldvalue | +------------+-------+-----+----+----------------------------------+ | 89 | 6 | 010 | a | 99176053 | | 90 | 6 | 020 | a | 1565922433 | | 91 | 6 | 035 | a | (DLC) 99176053 | | 92 | 6 | 035 | a | (OCoLC)39872119 | | 93 | 6 | 852 | k | TB | | 94 | 6 | 100 | a | Christiansen, Tom. | | 95 | 6 | 245 | a | Perl cookbook / | | 96 | 6 | 260 | c | c1998. | | 97 | 6 | 300 | a | xxxiv, 757 p. ; | | 98 | 6 | 300 | c | 24 cm. | | 99 | 6 | 650 | a | Perl (Computer program language) | | 100 | 6 | 650 | a | Perl (Computer program language) | | 101 | 6 | 090 | c | 6 | | 102 | 6 | 090 | d | 6 | | 103 | 6 | 952 | b | RH | | 104 | 6 | 952 | d | RH | | 105 | 6 | 952 | u | 5 | +------------+-------+-----+--------------+------------------------+ 17 rows in set (0.00 sec)
Have 852 and 952 got mixed up somewhere? (RH, ie Roger Horne, is what I would have expected to see in "location" on a search.)
But it turns out to be more complicated ... On a simple search the location of the Perl Cookbook shows correctly as Roger Horne (although it doesn't in a Marc search). But the location of the Mysql Cookbook doesn't show as Roger Horne in a simple search but as a blank (but shows as TB in a full search). There are very small differences in the marc_subfield_table but nothing that would appear to cause this:
+------------+-------+-----+--------------+----------------------------------------+ | subfieldid | bibid | tag | subfieldcode | subfieldvalue | +------------+-------+-----+--------------+----------------------------------------+ | 69 | 5 | 010 | a | 2002281940 | | 70 | 5 | 020 | a | 1930110065 | | 71 | 5 | 035 | a | (OCoLC)ocm49871541 | | 72 | 5 | 852 | k | TB | | 73 | 5 | 100 | a | Petersen, Theo. | | 74 | 5 | 245 | a | Web development with Apache and Perl / | | 75 | 5 | 260 | c | c2002. | | 76 | 5 | 300 | a | xviii, 410 p. : | | 77 | 5 | 300 | b | ill. ; | | 78 | 5 | 300 | c | 24 cm. | | 79 | 5 | 650 | a | Perl (Computer program language) | | 80 | 5 | 650 | a | Web site development. | | 81 | 5 | 650 | a | Open source software. | | 82 | 5 | 650 | a | Open source software. | | 83 | 5 | 090 | c | 5 | | 84 | 5 | 090 | d | 5 | | 85 | 5 | 952 | u | 3 | | 86 | 5 | 952 | b | RH | | 87 | 5 | 952 | d | RH | | 88 | 5 | 952 | u | 4 |
Roger -- Roger Horne, 11 New Square, Lincoln's Inn, London WC2A 3QB mailto:roger@number7.demon.co.uk
------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Koha-devel mailing list Koha-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/koha-devel
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com
participants (6)
-
genjimoto＠ezysurf.co.nz -
Joshua Ferraro -
MJ Ray -
paul POULAIN -
Roger Horne -
Stephen Hedges