Time  Nick  Message
19:03 cht   greetings kohateers!
19:03 cht   chris - r u there?
19:05 cht   i've been working on that problem i have where default (i.e. '*") issuing rules trump specific issuing rules
19:05 cht   i am beginning to suspect that i have discovered another small difference with mysql 5
19:06 cht   for those of you who do not know, i am running koha 2.2.6 and mysql 5.0 on debian sarge
19:07 cht   around line 628 in C4/Circulation/Circ2.pm, there is a check to see if $result is defined
19:08 chris k
19:08 cht   the expectation being that zero rows in the db yields an undefine $result...
19:08 cht   however, even though the query returns zero rows, perl is finding that $result is defined
19:09 chris interesting
19:09 cht   is it possible that with mysql 5 and koha's DBI code, result sets with zero rows are defined?
19:09 chris could be
19:10 chris koha doesnt use its on DBI code
19:10 chris it uses DBI.pm
19:10 cht   **OR** - i updated to the very latest DBI/DBD perl modules - that could explain it too
19:10 chris yeah
19:10 cht   there was a new release for one of them last week
19:10 chris if you change that line to
19:11 chris if (defined($result) && $result->{'itemtype'}) {
19:11 chris then it oughta work for both
19:11 cht   actually - scratch the DBI/DBD possibility as my users in the cooks have this problem too and they are using an older module
19:12 chris actually it would need to be
19:12 cht   i'll try that chris
19:12 chris oh no that oughta work
19:12 chris the other thing to check
19:13 cht   k?
19:13 chris is if there isnt some way to get DBI to check the rows returned
19:13 cht   i was thinking of that
19:14 cht   one would think that you could
19:17 cht   well, that change made rule 'a' not match, which is an improvement. now rule 'f' around 669 is matching
19:18 chris yeah you will have to do the same thing for all the if's
19:20 cht   hmm
19:20 chris or at least
19:21 cht   is this a bug or something that is only relevant in the unsupported 2.2.6+mysql5 scenario?
19:21 chris well i havent run into it before
19:21 cht   i suppose the latter
19:21 chris so im guessing so
19:21 cht   what's up with katipo and liblime?
19:22 chris russ, mason and I will be working for liblime after april 1
19:22 cht   cool
19:23 cht   the rest of katipo remains katipo?
19:23 chris yep, as far as im aware yep
19:23 cht   exciting news, my friend
19:23 chris ahh heres what i have done
19:24 chris  if (defined($result->{maxissueqty})) {
19:25 cht   interesting
19:27 cht   that change will not help with rule 'f', which has defined($result) && $result->{maxissueqty} ge 0
19:28 chris yeah
19:28 chris rule f looks ok
19:31 cht   i'm going to get some caffiene and then come back and loojk at this fresh
19:32 cht   back in a bit
21:48 cht   well, i did some more investigation...
21:48 cht   ahfter playing around with the if statements for a while...
21:48 cht   (btw - DBI supports $sth->rows for row counts)
21:49 cht   i am back to thinking that the logic of the TooMany sub in Circ2.pl in koha 2.2.6 is just plain wrong
21:51 cht   if you have your issue rules set so that an ADULT borrower can borrow 6 FICTION items and your * default borrower can only borrow 3 FICTION items...
21:51 cht   you will always get the issuing warning when you lend out the 4th FICTION item to a borrower belonging to ADULT
21:52 cht   this result, as far as I can tell, has nothing to do with the underlying DB type or version
21:54 cht   try it on your install
21:56 cht   if one leaves both the * row and the * column blank, this problem does not surface, OR if your set your default number of books as high as your highest borrower category
21:56 cht   am i crazy?
22:02 cht   scratch one earlier comment: leaving the * row blank causes borrowing limits of 0
08:58 toins hi #koha