- Koha - lists.katipo.co.nz

Import into catalogue failed, cannot un-import
by Jeffrey LePage 22 Dec '08

22 Dec '08

Hello all: Because of a character set issue, an import of some MARC records failed. I can't simply reverse the import from the web interface. The import crashed and the web interface doesn't seem to recognize that the import happened. However, the records are still there in the database tables biblio, biblioitems, and items. My question is: Can I simply delete all records from these tables (biblio, biblioitems, items)? Or are there other tables I need to deal with? Or is there a way to do this from the web interface? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html P.S. Bernardo Gonzalez Kriegel informs me that the problem I had with the character set was due to not using UTF-8 encoding. I believe this is correct, although I haven't yet had a chance to test it. Thanks Bernardo!

2 1

FreeBSD Dependencies
by Patrick Bachelier 22 Dec '08

22 Dec '08

Hi, I have to install KOHA on a FreeBSD 7.0 Release operating system (my choice). Do you know where a can find informations concerning the installation. I will prefer install KOHA on FreeBSD rather on an another OS because it is a good system. We could coordinate our research and works. Thanks for your help Kind regards Patrick BACHELIER http://tutti-free.com <http://tutti-free.com/> P.S. : Excuses-me for my english :-)

3 2

problem importing MARC records, probably a character set issue
by Jeffrey LePage 21 Dec '08

21 Dec '08

People, I've been working on converting an Athena-exported bunch of MARC records to a format Koha likes. My latest script seems to convert everything nicely except... ...Around the 117th entry the import into catalogue fails. On inspection I detected a non-ascii character in the 117th record. Specifically, it's an 'e' with an accent, as in Andre'. This is the first time in the file that a non-ascii character ( a character above 127 ) occurs. Has anyone had experience with this? I'm using MARC::Record, MARC::Field, etc. to do the conversion. Interestingly, the MARC files that come directly from Athena import just fine (except that the barcode info doesn't get imported because of the 852/952 issue). I'll post more details after I get some sleep. -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html

1 0

Athena to Koha mapping, specifically 852$k, $h$i, $m to 952$o
by Jeffrey LePage 21 Dec '08

21 Dec '08

Hello Everybody, I'm working on migrating from Athena to Koha, and I want to double-check one thing. John Rose suggests this mapping: Athena 852 $k prefix, $h main, $i cutter, $m suffix ...becomes... Koha 952 $o. In a post (http://lists.katipo.co.nz/public/koha/2005/009105.html) from 2005, Tim McMahon suggests the same mapping and further says that 852 $k,$h,$i,$m be combined as a _space_ separated list. My question is this: is the ordering correct ($k,$h,$i,$m) and should Koha 952$o be a comma separated or space separated list? -- Please avoid sending me Word or PowerPoint attachments. See http://www.gnu.org/philosophy/no-word-attachments.html --- On Tue, 12/9/08, John Rose <jrose3(a)gmail.com> wrote: > From: John Rose <jrose3(a)gmail.com> > Subject: Copy of koha subfields.xls > To: "'Jeffrey LePage'" <jeffrey_lepage(a)yahoo.com> > Date: Tuesday, December 9, 2008, 10:05 AM > this may help some > > what you want to load is a file of MARC records with > multiple items attached > (repeating 952 tags).. > > > will have your file back to you in a bit > > > john

1 0

FreeBSD Dependencies
by Patrick Bachelier 21 Dec '08

21 Dec '08

1 0

Re: [Koha] Community Feedback
by BWS Johnson 20 Dec '08

20 Dec '08

Salvete! >> I respectfully disagree. It's like a doctor saying that you'll need your leg >> amputated before trying physical therapy. >Sigh ... I can't even count how many ways it's NOT like that. That sigh and those caps typify the sort of negative community attitude that I'd rather avoid. I'm trying to offer constructive criticism and I'm being met time and time with condescension. >You seem to be aiming a lot of your frustration at LibLime. I'd argue >that we've done a very good job promoting just the spirit you're >saying the community is known for. I think we've specifically planned >for that, and have aired topics for discussion to plan for just that >type of project. I wonder why you think we have a lack of planning, >from my POV, it's quite the opposite. > You asked me to be specific, so I was. I think you all did a better job initially than now. I remember a time when there was one day a week where LibLime devoted itself to the community gratis. It wasn't carried on very long, but the gesture was important. Even if the interval were changed to be once a month or once a quarter, at least it would be there. What I've not seen, that I think we ought to see the project do, would be for a friendly (yes friendly!) coding competition. They happen all the time on different projects. People really get into them and stuff gets done. It could be like coding field day, and we could fabricate some sort of ridiculous looking Kiwi trophy. Let's put the fun back into the project. >This is over on the other thread, where this started, before you >changed threads on me, so I'll paste it in again: I changed threads since this doesn't much have to do with acquisitions and does have to do with community feedback. > >My perception is that you're coming at this from the perspective of a >library who's downloaded Koha on your own, and who's been active in >the community with respect to documentation and help on the various >mailing lists, right? ie, you haven't signed up for support with a >Koha company, and you haven't contributed or sponsored any code, >right? BTW: I think that's just great, hats off to you for your >continued involvement and community support, it's much appreciated and >the community wouldn't be the same without you and others like you. > I didn't need support at a premium when my husband was more than capable of providing me with technical support. He's come close on a couple of occasions to contributing code. As it was, as the years went by and I spoke with Chris and Paul and others, I felt like my knowledge base was growing large enough to attempt an installation on my own. I'm still toying with the idea of taking a PERL class. This is like fundraising, Josh. Things grow over months and years. >However, things get tricky because as valuable as all those activities >you do are, they don't do help motivate Koha developers to change add >or improve code. This isn't the kind of open source community where I disagree heavily with this. I've had a number of conversations over the years off list with developers who took what I said, asked further probing questions, and would mock up a feature. You did this yourself with the MARC export feature over a lunch break. How much free testing with specific feedback on beta 3 did I provide you? The only reason I didn't do more then was that I felt insignificant. >we've got a bunch of volunteers contributing code out of the goodness >of their hearts ... over 90% of Koha is done by programmers who work >on Koha as a full time job (or two) to put meals on the table. I'm not sure how true this is anymore. It's a lot larger project now than it was a few years ago. Those same programmers that are putting meals on the table have also put free code back in. The list of the top contributors offers an interesting testimony over time. >Currently, the margins on Koha development are so low, many of us have >to supplement our Koha development work with other services just to >make ends meet. > And this, from another of your emails, is relevant here: >The reason is that none of the developers in this community get paid a >salary to work on it. That's the bottom line. The librarians get paid >a salary to use the system, and presumably that gives people like you >some time to spend doing great stuff like documentation, etc. But us >developers don't have salaries outside of our Koha work, so we only >have time to work on stuff we're paid for, it's as simple as that. My salary at Hinsdale was about $15,000. That was a raise from my predecessors. I was a lucky rural Librarian at that rate, too. I worked there for many reasons, one of them being that I didn't think it was fair that doctors and teachers could participate in programmes that situated them in either rural or urban settings of need and that there was no such programme for Librarians. There is more to life and Koha than money. >So from that perspective, the perspective of a starving developer, >what are your thoughts on how we developers can both keep our stomachs >full (not to mention mortgages, etc.), and fulfill the needs of users >like yourself? Some kind of voting mechanism that gives a weight of >voting based on dollars, and a commitment from the development >community to tap that resource for sponsoring voted-upon features? >It's a very interesting problem, and I'd love to hear your thoughts on >how we might solve it. There's a much wider pool at play though. I mentioned earlier in the email that I'd like to see a return to a free programming and development day where any user could show up in IRC or elsewhere and have the ear of a developer. If folks did this in rotation, it would be less of a stress on everyone. Voting by dollar is a terrible system. The current financial state of affairs points that out. That's how one ends up with fragmented feature laden code that doesn't have stability since it's not sexy to fund rewrites. I don't want to see that happen here. Why isn't there a rating system for users built into the roadmap? Why can't we prioritise features that aren't sponsored as a community that way the stuff that we want to see get done is seen to after the paid projects if that's going to be the way you approach things? We need to be thinking about the large picture. I think it's financially wasteful to *not* think about the big future trends as far in advance as possible. I'd also point out that you seem to be falling in the pitfall of assuming that what someone pays for isn't of interest to other users and vice versa. Also that people that aren't currently donating money or code to the project won't ever donate money in future. I feel like every contribution is meaningful and ought to be encourage instead of imposing a caste system of developer and non developer or paying client and riff raff. Cheers, Brooke

10 12

Upgrading from 2.2 to 3.0, not so smooth...
by PasiK 20 Dec '08

20 Dec '08

We tried to upgrade our Koha system from 2.2 to 3.0. Installation went ok, but data-conversion failed. Here are the error messages from update22to20.pl: Adding textmessaging field to deletedborrowers table... DBD::mysql::st execute failed: Unknown column 'faxnumber' in 'deletedborrowers' at ./update22to30.pl line 3071. **Error : DBI::st=HASH(0x88f6500)->errstr altering borrowers zipcode to zipcode altering deletedborrowers zipcode to zipcode altering deletedborrowers homezipcode to B_zipcode DBD::mysql::db do failed: Duplicate column name 'B_zipcode' at ./update22to30.pl line 3104. removing some unused fields... alter or create notify_id in accountlines alter or create notify_level in accountlines alter or create accountno in accountlines alter or create booksellerid in aqbasket alter or create bookfundid in aqbookfund alter or create branchcode in aqbookfund alter or create id in aqbooksellers DBD::mysql::db do failed: Multiple primary key defined at ./update22to30.pl line 3271. Error while executing: alter table aqbooksellers change `id` `id` int(11) NOT NULL PRIMARY KEY auto_increment at ./update22to30.pl line 3271. alter or create currency in aqbooksellers alter or create listprice in aqbooksellers alter or create invoiceprice in aqbooksellers alter or create invoicedisc in aqbooksellers alter or create bookfundid in aqbudget alter or create bookfundid in aqorderbreakdown alter or create ordernumber in aqorderdelivery alter or create currency in aqorders alter or create authtypecode in auth_header alter or create datecreated in auth_header alter or create origincode in auth_header alter or create authtypecode in auth_subfield_structure alter or create tagfield in auth_subfield_structure alter or create tagsubfield in auth_subfield_structure alter or create liblibrarian in auth_subfield_structure alter or create libopac in auth_subfield_structure alter or create authorised_value in auth_subfield_structure alter or create value_builder in auth_subfield_structure alter or create seealso in auth_subfield_structure alter or create kohafield in auth_subfield_structure alter or create frameworkcode in auth_subfield_structure alter or create authtypecode in auth_tag_structure alter or create tagfield in auth_tag_structure alter or create liblibrarian in auth_tag_structure alter or create libopac in auth_tag_structure alter or create authorised_value in auth_tag_structure alter or create auth_tag_to_report in auth_types alter or create summary in auth_types alter or create category in authorised_values alter or create authorised_value in authorised_values alter or create lib in authorised_values alter or create frameworkcode in biblio alter or create frameworkcode in biblio_framework alter or create frameworktext in biblio_framework alter or create itemtype in biblioitems alter or create dewey in biblioitems alter or create publicationyear in biblioitems alter or create collectiontitle in biblioitems alter or create collectionissn in biblioitems alter or create collectionvolume in biblioitems alter or create editionstatement in biblioitems alter or create editionresponsibility in biblioitems alter or create shelfname in bookshelf alter or create owner in bookshelf alter or create category in bookshelf alter or create cardnumber in borrowers alter or create surname in borrowers alter or create branchcode in borrowers alter or create categorycode in borrowers alter or create address in borrowers alter or create city in borrowers alter or create sex in borrowers alter or create branchcode in branches alter or create branchname in branches alter or create branchcode in branchrelations alter or create categorycode in branchrelations alter or create frombranch in branchtransfers alter or create tobranch in branchtransfers alter or create category_type in categories alter or create categorycode in categories DBD::mysql::db do failed: Multiple primary key defined at ./update22to30.pl line 3271. Error while executing: alter table categories change `categorycode` `categorycode` varchar(10) NOT NULL PRIMARY KEY default '' at ./update22to30.pl line 3271. alter or create frameworkcode in deletedbiblio alter or create itemtype in deletedbiblioitems alter or create dewey in deletedbiblioitems alter or create itemtype in deletedbiblioitems alter or create branchcode in deletedborrowers alter or create categorycode in deletedborrowers alter or create B_zipcode in deletedborrowers alter or create zipcode in deletedborrowers alter or create address in deletedborrowers alter or create city in deletedborrowers alter or create surname in deletedborrowers alter or create streetnumber in deletedborrowers alter or create streettype in deletedborrowers alter or create sex in deletedborrowers alter or create borrowernumber in issues alter or create itemnumber in issues alter or create return in issues alter or create categorycode in issuingrules alter or create branchcode in issuingrules alter or create itemtype in issuingrules alter or create homebranch in items alter or create holdingbranch in items alter or create itemtype in itemtypes DBD::mysql::db do failed: Multiple primary key defined at ./update22to30.pl line 3271. Error while executing: alter table itemtypes change `itemtype` `itemtype` varchar(10) NOT NULL PRIMARY KEY default '' at ./update22to30.pl line 3271. alter or create description in itemtypes alter or create summary in itemtypes alter or create marc in marc_breeding alter or create defaultvalue in marc_subfield_structure alter or create authtypecode in marc_subfield_structure alter or create tagfield in marc_subfield_structure alter or create tagsubfield in marc_subfield_structure alter or create authorised_value in marc_subfield_structure alter or create seealso in marc_subfield_structure alter or create tagfield in marc_tag_structure alter or create liblibrarian in marc_tag_structure alter or create libopac in marc_tag_structure alter or create authorised_value in marc_tag_structure alter or create frameworkcode in marc_tag_structure alter or create expirationdate in opac_news alter or create printername in printers alter or create printqueue in printers alter or create printtype in printers alter or create reservedate in reserveconstraints alter or create constrainttype in reserves alter or create branchcode in reserves alter or create planneddate in serial alter or create notes in serial alter or create branch in statistics alter or create datetime in statistics alter or create startdate in subscription alter or create histstartdate in subscriptionhistory alter or create enddate in subscriptionhistory removing some unused data... DELETE FROM userflags where bit = 8 synch'ing borrowers and deletedborrowers synch'ing items and deleteditems synch'ing biblio and deletedbiblio synch'ing biblioitems and deletedbiblioitems Updating publisheddate Checking for data required in table userflags... Checking for data required in table systempreferences... Checking for data required in table authorised_values... Adding row to authorised_values: authorised_value => Not enough budget lib => This book it too much expensive category => SUGGEST insert into authorised_values (authorised_value,lib,category) values (?,?,?)Checking for index required... Creating index borrowernumber in borrowers DBD::mysql::db do failed: Multiple primary key defined at ./update22to30.pl line 3408. Error alter table borrowers ADD PRIMARY KEY (borrowernumber) : DBI::db=HASH(0x885d484)->err Checking for foreign keys required... Creating foreign key items in accountlines Creating foreign key aqbookfund in aqorderbreakdown Creating foreign key biblio in aqorders Creating foreign key branches in borrowers Creating foreign key branchcategories in branchrelations Creating foreign key items in branchtransfers Creating foreign key items in issues Creating foreign key branches in items Creating foreign key branches in items DBD::mysql::db do failed: Cannot add or update a child row: a foreign key constraint fails (`Koha/#sql-a58_52`, CONSTRAINT `#sql-a58_52_ibfk_5` FOREIGN KEY (`holdingbranch`) REFERENCES `branches` (`branchcode`) ON UPDATE CASCADE) at ./update22to30.pl line 3442. ==================== An error occured during : alter table items ADD FOREIGN KEY holdingbranch (holdingbranch) REFERENCES branches (branchcode) on update CASCADE on delete RESTRICT It probably means there is something wrong in your DB : a row (items.holdingbranch) refers to a value in branches.branchcode that does not exist. solve the problem and run updater again (or just the previous SQL statement). You can find those values with select items.* from items where holdingbranch not in (select branchcode from branches) ==================== Creating foreign key biblio in reserves Creating foreign key items in reserves Creating foreign key branches in reserves Creating foreign key bookshelf in shelfcontents DBD::mysql::db do failed: Can't DROP 'borrowernumber'; check that column/key exists at ./update22to30.pl line 3531. upgrade to Koha 3.0 done At the moment we are able to access Koha via browser, but there are no biblios in the database (borrower information, branches and such seem to be there, however). There is a number of biblios in the database that don't have item information and we are also using some non-marc21 fields. Could this be the cause? Ideas for fixing this? -- View this message in context: http://www.nabble.com/Upgrading-from-2.2-to-3.0%2C-not-so-smooth...-tp20934… Sent from the Koha - Discuss mailing list archive at Nabble.com.

3 5

Community Feedback
by BWS Johnson 20 Dec '08

20 Dec '08

Salve! >>Finally, I'd again like to point out that out and out removal of functionality is not a bug solution. > >It may not be a solution for the feature, but it is a bug solution *for that release version*. > I respectfully disagree. It's like a doctor saying that you'll need your leg amputated before trying physical therapy. >>If it were bugged, then I as a user would like whatever bug (or more likely combination of bugs) it was >fixed before something new was added to the core programme. > >Easily said, but practically impossible to accomplish. And surely other users would prefer to have their >favorite feature integrated into a release without waiting for every outstanding bug in unrelated, orphaned >features to be addressed, especially if they are paying developers to accomplish just that. > The prevailing attitude in this community prior to arrival of LibLime was that features and Libraries would not be orphaned and left high and dry. I used to be very proud to go out and speak to others about the quality of the programme and the compassion of the community. The more I see the attitude that if you're not a developer, we don't care what your opinion is, the less likely I am to recommend it to a friend. The Koha release date has nothing to do with a custom contract that LibLime promises to a paying customer. A solution is easily bundled and shipped out to that client. LibLime's lack of planning is not my emergency, nor are their vendor promises. It isn't practically impossible to fix what's broken, it'll just take time. It's better to wait longer, schedule things out with a longer lead time, and have a better product at the end of the day then to have a Frankenstein's monster of features since there's this silly notion that stuff has to be done quickly. I fail to see why nagging problems, like acquisitions, cataloguing, the installer and spine labels aren't being given a better once over between releases to get them user friendly and nearly bug free. There's been progress, but there's a lot of traffic on the list for the same errors year in and year out. How is this beneficial to anyone? I'm aware that folks like MJ are all over QA, and I very much appreciate that. When the roadmap is set, just factor more time in. I've seen some of this stuff slated for next week or next month with an initial feeling that it would take much longer. Why put yourself through that? Better planning will avoid folks getting impatient. > >>If removal is the only option, I don't think it's asking to much to take a poll on this list instead of solely >>discussing things on the developer's list. > >A poll doesn't matter much when there isn't code to back it up. So you'd prefer to develop in a vacuum? > I think it would be counterproductive to >conduct a poll that suggests itself as a mechanism to accomplish something when in fact it is unrelated to >accomplishing it. If the group being polled had a developer they could dedicate to the task(s), or even a >set number of developer hours, then it would be a totally different situation. > There are developers on this list as well. Why would anyone want to pay for something they've no say in? >I hope you don't mean that you've been waiting 27 years for an implementation! (Koha of course hasn't >been around half that long.) > Nope, but I knew people that did on a different ILS. Koha develops much more rapidly than other ILSs, which is nice. But I'm now worried about losing quality. We've a nearly mature product now. I think some real time in thinking over what we do in Release 4 or later is warranted. I truly believe that that has to happen _here_ and not solely on the developer's list. I'd like to see things work out of the box for different Library sizes and types. >I'm not sure what features/dates you are referring to, or who you think promised them. But in general, >for a codebase that is moving rather quickly, I think the developer community has been reasonably >pragmatic in its decisions. > There were numerous release dates slated for 3 that I feel should have been scheduled for further in the future. As a result, numerous dates that were slated on the roadmap were not met. It would have been better to just set the date for release further in the future than to have to scrap the date time and again. I know I was getting antsy for release after 2 or 3 of them were missed. I realise that the codebase is moving rather quickly, but if that's disorientating to users and developers alike, then perhaps it's time to put on the brakes a bit. Cheers, Brooke

9 10

Re: [Koha] getting code from TTLLP's repository into Koha (was: Community Feedback)
by Andrew Moore 20 Dec '08

20 Dec '08

On Fri, Dec 19, 2008 at 6:23 AM, MJ Ray <mjr(a)phonecoop.coop> wrote: > Maybe in the main repository but that's mainly because we have no > access. I'm doing a hell of a lot of QA for customers and friends > (probably 90% QA and 10% development which is not how I want to be > working) so we've a very stable local koha branch but the changes have > not been getting pushed upstream quickly because we felt our funders' > priorities (usually stability) and the koha.org release managers' > priorities (usually new features) seem different enough to make that > difficult and I hate trying to negotiate with LibLime developers when > I don't have enough resources to do it well and now apparently I've > broken TTLLP's public repository so people can't even pull from there > (not that any release managers have ever seemed interested in that) > and there just aren't enough hours in the day because... Hi MJ - Could you point me at that repository, please? I briefly searched for it unsuccessfully. I'd love to keep an eye on it and see if there are any patches I could help move over. Or, if you have any that you think would be particularly helpful, feel free to use 'git format-patch ; git send-email' to send them on to the patches(a)koha.org list. Thanks! -Andy

2 1

koha
by vinod kumar 20 Dec '08

20 Dec '08

1 0