Re: [Koha] 3.6.1 updatedatabase.pl [was: Checkout fails]
At 09:46 AM 12/16/2011 -0500, Owen Leonard wrote:
Duplicate entry 'maxItemsInSearchResults' for key 'PRIMARY'
"Duplicate entry" means that the update is trying to make a change that has already been made. That's why it's safe to ignore.
Thanks, and yes -- but what I was trying to research was *why* the Perl script was trying to do it twice (I am sure that whoever wrote it had a good reason for that particular line appearing at that particular place.) Also, I understand the functionality of 'maxItemsInSearchResults', but not that of 'privacy' ... I'll be taking a closer look at these sort of details, but at the moment am more concerned with system security, reliability and speed (Paul P. has made some interesting suggestions on the developers' list) as I want to get the new server into production on 1 Jan and this includes the customization (automated barcodes and call numbers via our own Perl modules, frameworks and screen presentations.) For example, I see that search is now giving us under "Location": 1 item, None available 1 unavailable Archives and Collections {correct shelf location} (Damaged) not for loan whereas there is in fact 1 item available, reference only, (Normal wear) not for loan The devil is in the details ... but we're having fun. Again thanks - and best regards, Paul
Hi Paul, On Fri, Dec 16, 2011 at 11:10 AM, Paul <paul.a@aandc.org> wrote:
At 09:46 AM 12/16/2011 -0500, Owen Leonard wrote:
Duplicate entry 'maxItemsInSearchResults' for key 'PRIMARY'
"Duplicate entry" means that the update is trying to make a change that has already been made. That's why it's safe to ignore.
Thanks, and yes -- but what I was trying to research was *why* the Perl script was trying to do it twice (I am sure that whoever wrote it had a good reason for that particular line appearing at that particular place.) Also, I understand the functionality of 'maxItemsInSearchResults', but not that of 'privacy' ...
I'll be taking a closer look at these sort of details, but at the moment am more concerned with system security, reliability and speed (Paul P. has made some interesting suggestions on the developers' list) as I want to get the new server into production on 1 Jan and this includes the customization (automated barcodes and call numbers via our own Perl modules, frameworks and screen presentations.)
This "bug" in the updatedatabase.pl script poses neither security nor reliability problem. It may affect speed, but probably very little and updatedatabase.pl is only called if the version in kohaversion.pl and the one in the current systemspreference table do not match. I see no reason why the errors you posted in this thread should/would affect the ability to put a server into production. HTH Kind Regards, Chris
participants (2)
-
Chris Nighswonger -
Paul