Time  Nick    Message
11:55 hdl     owen :
11:55 hdl     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 owen    Paul, I wanted to be sure to have a copy of our discussion of the new not for loan settings.
12:02 owen    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 hdl     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 kados   sorry ... hlt ;-)
12:07 paul    hi kados
12:07 paul    so they work...
12:07 paul    and what do we have to do now ?
12:07 kados   I think so ... actually they are very useful for stats ...
12:08 kados   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 owen    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 owen    Homebranch will not be accurate, if the holdingbranch is different.
12:32 owen    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 paul    QUOTED
13:08 paul    for example, enter '700a','701a','702a'
13:08 paul    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 paul    (10)
13:48 kados   I don't quite understand how $date_due is getting passed correctly in SearchMarc.pm
13:49 kados   It looks to me like it's set only once per biblinumber ... instead of per itemnumber
13:49 kados   (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 kados   while (my $item = $sth_itemCN->fetchrow_hashref) {
13:52 kados   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 paul    sth_issues is :
13:53 paul    	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 kados   I'd like to redesign this section of SearchMarc
13:54 kados   for libraries with multiple branches
13:54 kados   if an item exists twice in a library
13:54 kados   it shows up as:
13:54 kados   Nelsonville
13:54 kados   Nelsonville
13:55 kados   Instead of "Nelsonville (2)"
13:55 kados   imagine if we have 7 of an item!
13:55 kados   in one branch ... it gets really ugly
13:58 kados   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 paul    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 paul    koha 2.0 ?
13:59 kados   because for multi-branch libraries this method does not work
13:59 kados   yes ... this was handled differently in Koha 1.x and 2.0
13:59 paul    right.
13:59 paul    maybe you could investigate on how katipo did this
14:00 paul    and find how to handle it in 2.2
14:00 kados   katipo doesn't use 2.2
14:00 kados   :-)
14:00 kados   I spoke with chris about this yesterday
14:00 kados   it will need to be fixed before katipo can use it
14:00 paul    i knew that.
14:00 paul    the solution would be probably to :
14:01 paul    * have an array of %lineCN
14:01 paul    * add a ùlineCN{numberofitems}
14:02 paul    * on each loop step, check if the item exists with same status. If yes, just numberofitems++
14:02 paul    * push @CNresults,@ournewarray outside the loop
14:02 paul    (just after)
14:02 paul    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 kados   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 kados   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 kados   or inconsistent at least
14:10 owen    It depends on what situation you mean
14:10 owen    We have plenty of records with correct series entries
14:10 owen    Just not all the things people expect
14:11 owen    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 owen    ...biblio.title;
14:11 kados   well ... try a different order-by
14:12 kados   (so this query works in mysql but not in search.pl?
14:12 owen    Not in either place.
14:12 owen    But when I query marc_subfield_table for 490a values, this item came up:
14:13 owen    490 | a            | The world of Snoopy.
14:13 owen    So my 'snoopy' search should have brought that up as well, I thought.
14:13 owen    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 kados   that's in preferences
14:14 kados   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 owen    No, because 440a is the only thing linked to biblio.subtitle.
14:15 owen    Or maybe I'm wrong.
14:15 kados   wait ... it's showing up in the query
14:15 kados   so it's right ...
14:15 kados   must be a query problem
14:15 kados   hmmm, there's no % after the words
14:15 kados   try it with a %
14:16 kados   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 kados   select from marc_word where word like 'snoopy%' and tagsubfield like '490a';
14:18 kados   huh ... it's empty
14:18 kados   but 440 works
14:19 kados   select * from marc_word where word like 'snoopy%' and tagsubfield in('440a', '490a');
14:19 kados   that works too
14:20 owen    But they're all from 440a.
14:20 owen    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 kados   quite a bit actually
14:22 owen    ...but 'snoopy' just isn't in there.
14:23 owen    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 kados   this works ... it returns three results in mysql
14:24 kados   | 124603 |
14:24 kados   |  66832 |
14:24 kados   |  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 kados   that sounds like a major problem
14:25 kados   :-/
14:25 owen    select tag, subfieldcode, subfieldvalue from marc_subfield_table where tag = 490 and subfieldcode = 'a' limit 0,10
14:25 owen    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 kados   if that fixes it it means that I need to drop the marc_word table before I do the upgrade
14:27 kados   (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 owen    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 owen    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 owen    As far as I know
14:35 kados   hmmm
14:36 kados   can you point me in the direction of a well-functioning series title search?
14:36 kados   it might help if I understood what we're attempting here ;-)
14:36 owen    http://66.213.78.67/cgi-bin/koha/opac-detail.pl?bib=125040
14:36 owen    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 kados   (in opac-detail)
14:39 owen    http://66.213.78.67/cgi-bin/koha/opac-detail.pl?bib=242
14:45 kados   SimpleMarc.pm:    '490'=>{'a'=>{name=> 'seriestitle',   rpt=>0, striptrail=>',:;
14:46 owen    ?
14:52 owen    Maybe we could add something like Paul's query of marc notes
14:52 owen      ## get notes and subjects from MARC record
14:52 owen    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 kados   if even
14:54 kados   and tell the catalogers to start using 440a instead of 490a
14:55 kados   (do you know why both are being used?)
14:55 owen    Because they're DIFFERENT!!!1
14:55 owen    ;)
14:55 owen    http://www.loc.gov/marc/bibliographic/ecbdsers.html
14:55 owen    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 owen    Duh!
14:56 owen    :)
14:56 kados   god damn it!
14:57 kados   so ... we actually want 440a, and 440p
14:57 kados   and 490a, p if 440a, p don't exist ... right?
14:58 kados   (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 owen    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 kados   we'll make a new subroutine
15:00 kados   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 kados   73075
15:02 kados   select count(*) from marc_word where tagsubfield like '490a';
15:03 kados    3481
15:03 kados   select count(*) from marc_word where tagsubfield in('490a', '440a');
15:03 kados   76556
15:07 kados   select count(distinct bibid) from marc_word where tagsubfield in('440a', '490a');
15:07 kados   23590
15:57 owen    Nice to be in The Plains and not have to work through my lunch :)
16:10 owen    Something else for the to-do list: http://66.213.78.67/cgi-bin/koha/opac-detail.pl?bib=34
16:10 owen    Multiple series titles getting squished together.  Can we build a loop out of these so that each can be linked?
16:10 owen    I've added it to the wiki to-do list.
16:10 owen    ...which is growing rather than shrinking :(
16:25 kados   yea :-)