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