IRC log for #koha, 2005-03-06

← Previous day | Today | Search | Index

All times shown according to UTC.

Time Nick Message
11:55 hdl owen :
11:55 I can mail you the log if you like.
12:02 owen thanks!
12:02 paul you also can ask Paul owen, he's awake ;-)
12:02 owen That worked really well.  I've never tried a transfer like that before.
12:02 Paul, I wanted to be sure to have a copy of our discussion of the new not for loan settings.
12:02 Because I knew I wouldn't be able to look at that stuff again in a little while
12:03 hdl owen : you're welcome. first try on DCC transfer ;)
12:06 Direct connection client to client
12:06 kados hi all
12:06 hdl Paul : formes rejetées et associées, ca a a voir avec les authorités. kados : hi
12:06 kados paul I talked to chris yesterday: htl does use transfers
12:07 sorry ... hlt ;-)
12:07 paul hi kados
12:07 so they work...
12:07 and what do we have to do now ?
12:07 kados I think so ... actually they are very useful for stats ...
12:08 someday NPL should consider switching ... but Chris would like to expand the functionality a bit
12:08 owen It was an interesting discussion--they use transfers instead of returns to change the holdingbranch because they want to retain correct statistics regarding returns and transfers.
12:08 kados right
12:09 owen However, I don't think NPL needs to have those statistics "clean" at the moment.
12:10 I also know that the staff appreciates not having to take the extra step to transfer something every time it goes into a cargo bag.
12:12 paul and, about our 1st question (search limit on homebranch instead of holdingbranch), do you think it's OK ?
12:13 owen I think it's okay for now, but ultimately we need to figure out a way to update the holdingbranch when a book is returned or transfered.
12:14 Homebranch will not be accurate, if the holdingbranch is different.
12:32 Can more than one MARC subfield be mapped to the same koha field?
12:34 paul it may work. (But would be a surprise ;-) )
12:34 owen Perhaps it would only work if the two MARC subfields were never in the same MARC record at the same time?
12:37 paul not sure.
12:45 owen Or perhaps I should tell the catalogers to stop using both 440 and 490 and pick one! :)
12:48 paul highly more secure !
13:07 hdl re
13:08 owen paul, do the 'see also' values in marc_subfields_structure determine which other tags are searched at the same time?
13:08 paul yes
13:08 QUOTED
13:08 for example, enter '700a','701a','702a'
13:08 WITH the quotes. Otherwise, all searches will fail (sql error)
13:08 owen So if biblio.subtitle is linked to 440a, but I want a series search to also retrieve 490a, then I could add a see also '490a'?
13:22 paul owen => right.
13:22 sylvain time for the week end, bye all !
13:48 kados paul around?
13:48 paul yes, but only for a few miunts
13:48 (10)
13:48 kados I don't quite understand how $date_due is getting passed correctly in SearchMarc.pm
13:49 It looks to me like it's set only once per biblinumber ... instead of per itemnumber
13:49 (it works, I'm just not sure how ;-)
13:50 paul mmm... which line ?
13:50 kados in my SearchMarc (with some modifs) it's about 420 or so
13:52 while (my $item = $sth_itemCN->fetchrow_hashref) {
13:52 right after this line ^^
13:52 paul i don't understand your problem : date_due is retrieved from $sth_issue, that is related to issues
13:52 sth_issues is :
13:53 my $sth_issue = $dbh->prepare("select date_due,returndate from issues where itemnumber=?");
13:53 kados so it's only called once then (in that iteration)
13:54 I'd like to redesign this section of SearchMarc
13:54 for libraries with multiple branches
13:54 if an item exists twice in a library
13:54 it shows up as:
13:54 Nelsonville
13:54 Nelsonville
13:55 Instead of "Nelsonville (2)"
13:55 imagine if we have 7 of an item!
13:55 in one branch ... it gets really ugly
13:58 paul do you have any suggestions on how to best acomplish that?
13:58 paul not really. I think it won't be easy
13:58 because you have not to merge items with differents status.
13:58 kados yea ... I discovered that yesterday
13:58 paul (on issue, not forloan...)
13:58 kados yea ...
13:58 paul that's why i ignore this case :-(
13:58 kados well can we roll back to Koha 2.0 then
13:59 paul (ignored)
13:59 koha 2.0 ?
13:59 kados because for multi-branch libraries this method does not work
13:59 yes ... this was handled differently in Koha 1.x and 2.0
13:59 paul right.
13:59 maybe you could investigate on how katipo did this
14:00 and find how to handle it in 2.2
14:00 kados katipo doesn't use 2.2
14:00 :-)
14:00 I spoke with chris about this yesterday
14:00 it will need to be fixed before katipo can use it
14:00 paul i knew that.
14:00 the solution would be probably to :
14:01 * have an array of %lineCN
14:01 * add a ùlineCN{numberofitems}
14:02 * on each loop step, check if the item exists with same status. If yes, just numberofitems++
14:02 * push @CNresults,@ournewarray outside the loop
14:02 (just after)
14:02 should not be so hard finally...
14:06 owen kados, you know how the error log shows the sql statement from searches?
14:07 kados yep
14:07 what about it?
14:07 owen I was going to ask why it wasn't returning anything when I paste it to the mysql prompt, but I may be pasting the wrong query...
14:08 kados I'm also not sure how the "AS" statements work diretly in the prompt
14:09 iirc I've used those queries directly before
14:09 owen I'm trying to figure out why these series searches aren't working.
14:10 kados huh ... I thought it was due to incorrect marc records
14:10 or inconsistent at least
14:10 owen It depends on what situation you mean
14:10 We have plenty of records with correct series entries
14:10 Just not all the things people expect
14:11 I can't seem to bring up any results from the 490 tag, though, even though it looks like it's querying it.
14:11 kados huh ...
14:11 owen select distinct m1.bibid from biblio,biblioitems,marc_biblio,marc_word as m1,marc_word as m2 where biblio.biblionumber=marc_biblio.biblionumber and biblio.biblionumber=biblioitems.biblionumber and m1.bibid=marc_biblio.bibid and (m1.bibid=m2.bibid) and ((m1.word  like 'world' and m1.tagsubfield in ('440a','490a'))and (m2.word like 'snoopy' and m2.tagsubfield in('440a','490a'))) order by...
14:11 ...biblio.title;
14:11 kados well ... try a different order-by
14:12 (so this query works in mysql but not in search.pl?
14:12 owen Not in either place.
14:12 But when I query marc_subfield_table for 490a values, this item came up:
14:13 490 | a            | The world of Snoopy.
14:13 So my 'snoopy' search should have brought that up as well, I thought.
14:13 It's as if it's not really searching 490a, just 440a.
14:14 kados do we have 490a as a 'see also' for 440a?
14:14 that's in preferences
14:14 iirc
14:14 owen Yes.
14:14 kados strange ...
14:14 owen I wonder if the reverse needs to be the case as well?
14:15 No, because 440a is the only thing linked to biblio.subtitle.
14:15 Or maybe I'm wrong.
14:15 kados wait ... it's showing up in the query
14:15 so it's right ...
14:15 must be a query problem
14:15 hmmm, there's no % after the words
14:15 try it with a %
14:16 also not sure if caps matter ... I suspect not
14:16 owen No luck with the %
14:16 kados ok ... let's take a look at marc_word
14:17 select from marc_word where word like 'snoopy%' and tagsubfield like '490a';
14:18 huh ... it's empty
14:18 but 440 works
14:19 select * from marc_word where word like 'snoopy%' and tagsubfield in('440a', '490a');
14:19 that works too
14:20 owen But they're all from 440a.
14:20 Is marc_word not indexing 490a?
14:20 kados maybe not
14:20 owen No, because some things are there.
14:21 kados yep
14:21 quite a bit actually
14:22 owen ...but 'snoopy' just isn't in there.
14:23 Sketch, Skye, softly, Soho
14:23 kados select distinct m1.bibid from biblio,biblioitems,marc_biblio,marc_word as m1 where biblio.biblionumber=marc_biblio.biblionumber and biblio.biblionumber=biblioitems.biblionumber and m1.bibid=marc_biblio.bibid and (m1.word  like 'snoopy' and m1.tagsubfield in ('440a','490a')) order by biblio.title;
14:23 this works ... it returns three results in mysql
14:24 | 124603 |
14:24 |  66832 |
14:24 |  74531 |
14:24 owen Right, and those results are all in 440a tags
14:24 kados what's the difference?
14:24 owen But if you query marc_subfield_table for 490a tags, you get results with the word 'snoopy' in them
14:24 kados ahh
14:25 that sounds like a major problem
14:25 :-/
14:25 owen select tag, subfieldcode, subfieldvalue from marc_subfield_table where tag = 490 and subfieldcode = 'a' limit 0,10
14:25 That's the query that got me looking for snoopy in the first place.
14:25 kados wait ... I might know why
14:25 owen I was trying to find a record with a 490 tag in it.
14:26 kados I could try to rebuild marc_word with updatedatabase tonight
14:26 if that fixes it it means that I need to drop the marc_word table before I do the upgrade
14:27 (something I was planning for anyway ... this would just be the first legitimate reason to do it)
14:29 owen Of course even if that fixes it, we still don't see 490 tags in opac-detail.  That's a problem too. :(
14:33 kados why's that?
14:33 owen Why is it a problem?  Or why is it that we don't see the 490 tag?
14:34 It's a problem because if a series search turns up an item with a 490 tag, opac-detail should show the series title so that it can be linked back to another series search.
14:35 I think we don't see the 490 tag because only 440 is linked to biblio.seriestitle, and opac-detail grabs from there.
14:35 As far as I know
14:35 kados hmmm
14:36 can you point me in the direction of a well-functioning series title search?
14:36 it might help if I understood what we're attempting here ;-)
14:36 owen http://66.213.78.67/cgi-bin/ko[…]ail.pl?bib=125040
14:36 See how you can click the linked series title and get others in the series?
14:37 kados ooh that's nice
14:37 owen I added that this morning
14:38 kados so are there any examples where the title exists in 490 (in marc_word) but doesnt' display?
14:38 (in opac-detail)
14:39 owen http://66.213.78.67/cgi-bin/ko[…]detail.pl?bib=242
14:45 kados SimpleMarc.pm:    '490'=>{'a'=>{name=> 'seriestitle',   rpt=>0, striptrail=>',:;
14:46 owen ?
14:52 Maybe we could add something like Paul's query of marc notes
14:52  ## get notes and subjects from MARC record
14:52 at line 49 of opac-detail.pl
14:52 kados is that where 440a comes from?
14:53 owen No, that's a place where Paul has added a query to the MARC tables because the koha tables don't have the information we want
14:53 kados ahh ... so 440a comes from koha tables
14:53 owen the 440 tag comes from my $dat    = &bibdata($biblionumber);
14:54 kados maybe the easiest solution is to write a script to populate koha tables with 490a is 490a exists
14:54 if even
14:54 and tell the catalogers to start using 440a instead of 490a
14:55 (do you know why both are being used?)
14:55 owen Because they're DIFFERENT!!!1
14:55 ;)
14:55 http://www.loc.gov/marc/biblio[…]hic/ecbdsers.html
14:55 490 is a series statement for which no series added entry is traced or for which the added entry is traced in one of the 800-830 fields in a form different from the form contained in field 490.
14:55 Duh!
14:56 :)
14:56 kados god damn it!
14:57 so ... we actually want 440a, and 440p
14:57 and 490a, p if 440a, p don't exist ... right?
14:58 (maybe n and v while we're at it eh?)
14:58 owen I don't think $p is used enough to worry about it
14:58 How would we query to see if there are any records with both 440 and 490?
14:59 kados well ... do you mean just to check?
14:59 owen Yeah.  I'm curious whether they're mutually exclusive.
15:00 kados ok ... hmmm
15:00 owen Of course the catalogers will say that to convert 490 to 440 would be WRONG
15:00 kados well let's just do your suggestion then
15:00 we'll make a new subroutine
15:00 to grab the series title
15:02 owen I'm going to go get some lunch.  I'll be back in a bit.
15:02 kados select count(*) from marc_word where tagsubfield like '440a';
15:02 73075
15:02 select count(*) from marc_word where tagsubfield like '490a';
15:03 3481
15:03 select count(*) from marc_word where tagsubfield in('490a', '440a');
15:03 76556
15:07 select count(distinct bibid) from marc_word where tagsubfield in('440a', '490a');
15:07 23590
15:57 owen Nice to be in The Plains and not have to work through my lunch :)
16:10 Something else for the to-do list: http://66.213.78.67/cgi-bin/ko[…]-detail.pl?bib=34
16:10 Multiple series titles getting squished together.  Can we build a loop out of these so that each can be linked?
16:10 I've added it to the wiki to-do list.
16:10 ...which is growing rather than shrinking :(
16:25 kados yea :-)

← Previous day | Today | Search | Index

koha1