- Koha-devel - lists.koha-community.org

Re: [Koha] uninstalling
by Roger Horne 21 Apr '04

21 Apr '04

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

6 7

virus from poland
by paul POULAIN 19 Apr '04

19 Apr '04

Hi there, Today, I recieve between 10 & 20 mails per hour, that "say" they come from poland (almost all), and are sent on my koha-fr.org mailbox (paul_koha-fr.org) I think one of the polish guy involved in Koha, has got something bad in it's winshit. Here are some of the "sender" addresses : 3dartures1__wp mz.t__wp biuro.om__pttk.torun klub__ktk-przygoda.torun webmaster__petrus biuro__wedrowiec.krakow info__gniecki.prv madzia791__wp pracaulotki__wp (.pl removed in every adress & @ replaced by __) If someone know all the false "senders", then, it's probably the person infected. NB : the IP of the sender (the only true information) is always : 212.160.112.160 So, if one of the reader has it now, then it's him ! -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re:[Koha-devel] Re: [Koha] uninstalling
by lstamm＠telus.net 18 Apr '04

18 Apr '04

Roger Horne <roger(a)hrothgar.co.uk> writes: <snip> > 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 at least part of your problems are due to having NULL values in the itemtypes field. If you have anything else in this field other than the one of the values in the itemtypes table, all sorts of miscellaneous errors seem to happen. The first step in configuring Koha is to add values to the itemtypes table, and then make sure every catalogue item you enter has a valid itemtype in the 852 k field. > And I chose the budget based entry system. Unless you have a valid reason for using the budget based system (such as wanting to keep track of how much book value each person has contributed to your collection), I would suggest using the simple acquisition module instead. As the name suggests, it's simpler. :) Regards, -- Larry Stamm PO Box 561 McBride, BC V0J 2E0 Canada http://www.larrystamm.com

1 0

CVS symlinking
by Benedykt P. Barszcz 17 Apr '04

17 Apr '04

Hi group, I am trying to symbolically link the CVS tree with koha 2.0 but no success. Apache complains: [Sat Apr 17 17:23:39 2004] [error] [client 127.0.0.1] Symbolic link not allowed: /usr/local/koha/intranet/cgi-bin [Sat Apr 17 17:23:42 2004] [error] [client 127.0.0.1] Symbolic link not allowed: /usr/local/koha/intranet/cgi-bin Httpd.conf file has this: # KOHA's OPAC Configuration <VirtualHost localhost.localdomain:80> ServerAdmin kb2qzv(a)localhost.localdomain DocumentRoot /usr/local/koha/opac/htdocs ServerName localhost.localdomain ScriptAlias /cgi-bin/koha/ /usr/local/koha/opac/cgi-bin/ ErrorLog /usr/local/koha/log/opac-error_log TransferLog /usr/local/koha/log/opac-access_log SetEnv PERL5LIB "/usr/local/koha/intranet/modules" SetEnv KOHA_CONF "/etc/koha.conf" <Directory /usr/local/koha> Options Indexes FollowSymLinks </Directory> The above is just for the OPAC, the same is true for the INTRANET. Symbolic link is set to my cvs directory. I changed file ownership to apache.apache for the whole tree of the kohaCVS, and chmod -R 755, too. Any hints? Benedict

2 1

MARC-BN, how to implement
by Benedykt P. Barszcz 17 Apr '04

17 Apr '04

Hi, What would I need to actually add MARC-BN support to Koha? Here is a description of what marc-bn is: http://mak.bn.org.pl/wykaz5.htm It is in Polish but the differences between marc21 and marc-bn are clearly set further down the webpage. Any ideas? Benedict

1 0

New features to test in CVS
by paul POULAIN 16 Apr '04

16 Apr '04

I've commited some improvements in MARC search : * adding "suggestion" link in search form, that popup a windows. The popup windows shows, for each word entered in the search form, the 10 words that sounds like the word entered, and that are used most often. * fixes some minor bugs Still to do : * good support of ' and , Update your CVS & test it pls. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)

1 0

Re: 2.0 roadmap, was: uninstalling
by MJ Ray 15 Apr '04

15 Apr '04

Bouncing the devel parts onto devel list. On 2004-04-15 16:28:20 +0100 paul POULAIN <paul.poulain(a)free.fr> wrote: > I'm working a lot on HEAD branch to : > * clean some code > * css the templates. > * improve MARC searching & merge MARC & simple search. > The search is almost done. It could be ported to 2.0 probably, but > it's not a > trivial job, as it uses CSS & some other things that does not exist > in 2.0 DB > (like "seealso" field in MARC parameters) How many lines of code and files, roughly? I don't even know which files are affected, so it's hard for me to filter it out of the cvs logs. -- 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(a)jabber.at Creative copyleft computing services via http://www.ttllp.co.uk/

2 1

Re: [Koha-devel] Duplicate items in MARC tables
by Baiju M 15 Apr '04

15 Apr '04

>OK, I think I understand better : If I understand correctly, you have : >* created an iso2709 file with Koha export >* re-imported this iso2709 file. > >If i'm right, then, I think you've discovered a bug in export : the >090$b, 090$c and 952$u should NOT be exported, as they are purely >Koha-internal. >I think that's what confuses the imported. >Pls confirm & if you do, i'll send you a modified version of export >(that delete internal fields) Yes, I created an iso2709 file with Koha export tool and then re-imported this iso2709 file. Now, How I can import my holding information from another source? Thanks, Baiju M ____________________________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

2 1

Re: [Koha-devel] Duplicate items in MARC tables
by Baiju M 15 Apr '04

15 Apr '04

>2 questions : >* could you show us your iso2709 file ? >Use dumpmarc.pl script in misc directory (with bulkmarcimport). It can >be a "problem" in your iso2709 file. Here is the output of dumpmarc.pl (I created it by manually entering data using MARC interface of Koha) NUM : 0 NUMBER 1 => LDR 00307 2200133 4500 020 _a0471395307 090 _c1 _d1 100 _aShapiro, Alan C. 245 _aMultinational financial management 250 _a7th ed. 300 _axvi, 743 p. _fBOOK 508 _atom 852 _k658.15 952 _bMAIN _dMAIN _p1 _r100 _u1 _v02/02/04 ================== 2 record parsed Here is the output of same file dumped by using marcdump tool available with MARC::Record (Why "2 records parsed" message above?!) /home/kohaadmin/marc.pl LDR 00307 2200133 4500 020 _a0471395307 090 _c1 _d1 100 _aShapiro, Alan C. 245 _aMultinational financial management 250 _a7th ed. 300 _axvi, 743 p. _fBOOK 508 _atom 852 _k658.15 952 _bMAIN _dMAIN _p1 _r100 _u1 _v02/02/04 Recs Errs Filename ----- ----- -------- 1 0 /home/kohaadmin/marc.pl Now I run this command : $ sudo perl -I /usr/local/koha/intranet/modules \ /usr/local/koha/intranet/scripts/misc/bulkmarcimport.pl -d -file ~/marc.pl Again exported MARC records to marc1.pl, and here is the dumpmarc.pl output : NUM : 0 NUMBER 1 => LDR 00358 2200145 4500 020 _a0471395307 090 _c1 _d1 100 _aShapiro, Alan C. 245 _aMultinational financial management 250 _a7th ed. 300 _axvi, 743 p. _fBOOK 508 _atom 852 _k658.15 952 _bMAIN _dMAIN _p1 _r100 _u1 _v02/02/04 952 _bMAIN _dMAIN _p1 _r100 _u1 _u1 _v02/02/04 ================== 2 record parsed See there is one more 952 and in the second one there is an extra 952_u > >* how did you set you MARC21 parameters tables ? > Here is the MARC subfield structure for 952 : Subfield Lib Koha field Rep Mand Tab Auth value Thesaurus Val build b homebranch items.homebranch No No 10 branches d holdingbranch items.holdingbranch No No 10 branches p barcode items.barcode No No 10 r price items.price No No 10 u itemnumber items.itemnumber No No -1 v dateaccessioned items.dateaccessioned No No 10 y notforloan items.notforloan No No 10 Here is links to My marc_tag_structure and marc_subfield_structure SQL dumber files : http://forum.gnu.org.in/fsf-volunteers/Members/baiju/koha/test/mss.sql http://forum.gnu.org.in/fsf-volunteers/Members/baiju/koha/test/mts.sql Should I provide any other details? With thanks and regards, Baiju M ____________________________________________________________ Find what you are looking for with the Lycos Yellow Pages http://r.lycos.com/r/yp_emailfooter/http://yellowpages.lycos.com/default.as…

2 1

z3950 search 'loosing' forks
by T & J Kotula 14 Apr '04

14 Apr '04

Hi, I installed koha2.0.0 on the day it came out and was hoping I was going to install it in our library. However I just stumbled across another problem with the z3950 search :-( Here is what I've done. 1. Set up 9 z3950 servers. 2. Run ./processz3950queue from the command prompt 3. When search for the first time, 9 Processing ISBN=.... at server ... (n forks) lines appear, where n = 1..9. So far so good. 3b. After a few seconds they _all_ come back with 'no records found', followed by _all_ 'search done'. So far so good. 4. However when I search again, there are still 9 Processing ISBN=.... at server ... (n forks) lines, but this time n=5..13. 4b. After a few seconds they _all_ come back with 'no records found', followed by _all_ 'search done'. 5. When I search again, there are still 9 Processing ISBN=.... at server ... (n forks) lines, but this time n=9..17. 5b. After a few seconds they _all_ come back with 'no records found', followed by _all_ 'search done'. 6. The next search is different, as the script goes to line 325, which has a comment: # $forkcounter >=12 So (5-1) + (9-5) + would be (13-9) = 12. Bingo, the if stament falls through. Can someone please tell me how to fix or what I have possibly done wrong. Thanks tomasz kotula.

2 2