- Koha - lists.katipo.co.nz

Re: [Koha] MARC Import?
by Mathias Inderm�hle 17 Jan '03

17 Jan '03

Thanks for fast reply >So i hope that NOBODY uses it in real life :-) I know that this version is unstable.. but i realy miss the information in the INSTALL file, or informations about what features works and which non. (Z3950) >Ok, it does not work. Can you explain us what happends ? am, there was a just the message back that the file i try to import isn't a MARC Format or that there no ISBN number.. >Did you install from a fresh server or from a previously installed koha >1.2.x ? >Do you know how to completly remove a previous version ? First i Install 1.2.2.. but i can't get the Z3950 Import to run, and then the Version 1.3.3 released and i notice that u worked on this Part so i thought i try this. An then i get back to the 1.2.2. Everytime i drop the whole Koha Database, delete the C4 directory, chanche the Path of the Koha files (intranet and opac) save my httpd.conf and delete the koha.conf file ( i think thats everything ) the first time i installed the system manually (1.2.2 and 1.3.3) because i run Koha on Suse Linux 8.1. (this is why i miss the Install file :-) ) _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?page=features/virus

2 1

MARC Import?
by Mathias Inderm�hle 17 Jan '03

17 Jan '03

Hi All I'v some questions about MARC Imports.. first of all, does anyone of u work with Koha-1.3.3? I install it once but it seems that this release isn't realy ready.. I try to Import an MARC file which is made with BookWhere and the sample data file of the CPAN Perl Modul! but both don't work at all, then i try it on the test drive on the Koha webpage, and there it works properly. Now i go back to the Koha-1.2.2 and try it again on my system, because i thought its the same version like on the webpage (Koha server). But i just get the error that there is no uploadedmarc table in my Koha database, so i search in the koha.mysql file for the table, but there is non? Thanks for Help PS: Sorry bout my Englisch.. _________________________________________________________________ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE* http://join.msn.com/?page=features/virus

2 1

Re: [Koha] Where is the Supplier Information?
by Ingrid Lacis 17 Jan '03

17 Jan '03

I don't see any option/gateway to the full-acquistiions system. Where do I choose the full aquisitions system? At 07:11 PM 1/16/2003 -0500, Pat Eyler wrote: >Ingrid, are you using the simple-acquisitions system? > >-pate > >Pat Eyler >Kaitiaki/manager migrant Linux sys admin >the Koha project ruby, shell, and perl geek >http://www.koha.org http://pate.eylerfamily.org >On Thu, 16 Jan 2003, Ingrid Lacis wrote: > > > Hi - > > > > I'm testing Koha and I can't seem to locate the supplier information as > > illustrated in your documentation. > > (The vendor details, ordering information, shopping basket) > > > > Thank you, > > Ingrid Lacis > > > > _______________________________________________ > > Koha mailing list > > Koha(a)lists.katipo.co.nz > > http://lists.katipo.co.nz/mailman/listinfo/koha > >

3 2

Koha Mandrake
by ANNE Abdrahamane 17 Jan '03

17 Jan '03

Hello dear colleagues, I am trying without success to install Koha on Mandrake 8.2. Perl 5.6.1 is installed, Mysql and Apache are installed too. But two perl modules are missing : set::scalar, z3950. I don't know how to install this modules because I am used to install only *.rpm files. Is it possible to install koha without these modules ? ############### ANNE Abdrahamane DESS Ingenierie Documentaire ENSSIB Villeurbanne France ___________________________________________________________ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com

2 1

Re: [Koha] MySQL and foreign keys
by Joshua Brindle 17 Jan '03

17 Jan '03

This goes along with my other email about modularizing authentication. My feeling is that most of koha is sort of embedded, like auth the storage should be modularized, like this there should be a wrapper with default methods that do something a default way, one of those would be search. the mysql search would use mysql features (ie: full text search), a postgres search would do whatever they do. basically you'd have custom queries for each DBM since each method that does the querying would be DBM specific. Only the parent class would hold static variables and things that would be consistant across all the DBM's. If done this way storage is trivial, one could store everything in flat text files if they wanted!. I must emphasize that this is the *correct* way to program things like this, and if we (my university) decides to use Koha I will certainly help wherever i can. Joshua Brindle UNIX Administrator Southern Nazarene University >>> Chris Cormack 01/16/03 04:10AM >>> On Thu, Jan 16, 2003 at 11:02:43AM +0100, paul POULAIN said: > Chris Cormack a ?crit: > > >Hi There > > > >Just to throw in my 2 cents worth, i dont see using mysql fulltext > >searching > >as ruling out db independence. > >It just forces us to code more carefully, perhaps setting a value in > >/etc/koha.conf usefulltext=yes or the like. Which we can then use to > >decide > >whether to make a standard like search, or to use a fulltext index. > > > BUT : the standard like search is UNUSEABLE on a 50 000+ biblio DB, as > every search means a full parsing of the table. > If you add the same thing for the thesaurus table, which is widely used > in marc cataloguing, and some other place where full text indexing will > be usefull... > Hi Again paul :) Well maybe not 50,000 .. but 500,000+ ... its working ok for HLT's 78709 biblios. But I take your point, and agree wholeheartedly the current search code badly needs a rewrite and lots of optimisation. And im sure HLT wouldnt say no to any speed increase :-) I think what i was trying to say (bear in mind its getting late here, and my mind is probably muddled :-)) was that we should be able to provide the option for other people to use a database of their choice. Without restricting those who want to from using mysql fulltext indexing. On the topic of fulltext searching we had a discussion about it on irc today. I cant currently get to the irc logs but when i can, ill mark the discussion and post the url to the devel list. Chris -- Chris Cormack Programmer 025 500 789 Katipo Communications Ltd chris(a)katipo.co.nz www.katipo.co.nz _______________________________________________ Koha mailing list Koha(a)lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

4 4

Where is the Supplier Information?
by Ingrid Lacis 17 Jan '03

17 Jan '03

Hi - I'm testing Koha and I can't seem to locate the supplier information as illustrated in your documentation. (The vendor details, ordering information, shopping basket) Thank you, Ingrid Lacis

2 1

Re: some thoughts about cataloguing and acquisitions [important]
by Stephen Hedges 16 Jan '03

16 Jan '03

Hi, Paul, and thanks for opening an interesting topic - I think that a strong acquisition component would be a very valuable asset for Koha. In fact, I think acquisitions are much more important than cataloging. That means that I support your idea of separating the two, so it would be easier (to my mind) to focus development effort on acquisitions. If they are not separated, then I think cataloging should at least be handled as a sub-task of acquisitions. My thoughts are based on my experience with library users and librarians. We have found that library users appreciate the ability to make purchase suggestions and see what the library has on order, even place reservations on items before they arrive at the library. In other words, a good acquisitions system allows users to see not only what the library has, but what the library WILL have, and also gives them the power to suggest and reserve things the library has not ordered. That means the acquisition system needs to deal in records that are nearly complete, so people can search for items by title, author, ISBN, subject, etc. Cataloguing, in that case, merely adds the "labeling" to the item once it arrives, i.e. barcodes, spine labels, etc. The item has already been cataloged in all other respects as soon as it is ordered. As for librarians, I had a conversation with the tech guy from Worthington Public Library who suggested that they might be willing to put money toward a really good Koha acquisitions system, one that would allow the librarian to automatically search for an item and compare prices from several different vendors and download any MARC records available from vendors with a minimum of effort on the part of the librarian. He had other thoughts, as well, because he had been wrestling with searching for a good acquisitions system for some time, but I unfortunately can't remember them now. Both of these experiences lead me to believe that any ILS that wants to be competitive in the future should pay close attention to its acquisitions component. I think both library users and librarians are going to demand much more functionality than what is currently available in most ILS acquisitions systems. Stephen H. > I want here share some ideas for the 2.0 version > of koha, around > cataloguing and acquisition. > > Most ILS, in France at least, separate > cataloguing and acquisition. > * *cataloguing* is often done through a CDROM > (from the BNF for example) > : the librarian download from the cd the biblio > in MARC format, which is > included in it's ILS. The cataloguing refers only > to BIBLIO notice, not > items and how they arrive in the library. > * *acquisition* referers to how "books" arrive in > the library (and > includes items) > > In koha, at the moment, there is no distinction > between those 2 topics : > look at koha main page, there is only a > "acquisition" picture, which > includes cataloguing and acquisition in fact. > I want to begin de debate to see if it's a good > idea to distinct > acquisition and cataloguing in 2.0. > It would mean : > * in mainpage => 2 links for cataloguing and > acquisition > * acquisition => works almost like the normal > acquisition system of the > old version : search for a supplier, enter a > little part of the biblio... > * cataloguing => > - if marc is selected : works like the > acqui.simple in 1.3.3 (see > demo.koha-fr.org) > - if marc is not selected : works like the 2nd > part of the normal > acquisition in 1.2 : enter the biblio details. > this supposes a new parameter in the > systempreferences table. > > One other idea : it would enable a "suggestion" > feature in the opac : > readers could suggest books to add, which could > be stored in the > "acquisition" part of koha, in a "to validate" > status. > > From a developper point of vue, this means : > * duplicating biblio table to acqui_biblio table > * split normal acquisition in 2 parts > * change normal acquisition to write acqui_biblio > table and not biblio > * create some screens to link the acquisition > part and the cataloguing one. > some work, but not too much i think (if someone > wants to fund it, send > me a mail :-) ). > > Of course, if you create a book in the > acquisition part, all what you > typed would be auto-copied when entering the > cataloguing part :-) > So there should not be too much more work for the > librarian/cataloguer > (but a few, anyway : this would add screens, so, > more clics) > > -- > Paul POULAIN > Consultant indépendant en logiciels libres > responsable francophone de koha (SIGB libre > http://www.koha-fr.org) > >

1 0

RE: [Koha] MySQL and foreign keys
by Williams, Olwen - SAL 16 Jan '03

16 Jan '03

I'm not about to argue one database over another. I've worked a lot in databases that don't enforce integrity, and you need to include the integrity in your code. This is sometimes easier said than done. We began using Postgres at the very start of Koha, but found problems making some queries run efficiently. MySQL ran them so we changed. I don't know to what extent the problem were in my lack of experience and how much was the fault of Postgres, and how much the two database have changed in the meantime. -----Original Message----- From: Larry Currie [mailto:lcurrie@CalAcademy.Org] Sent: Thursday, January 16, 2003 1:38 PM To: koha(a)lists.katipo.co.nz Subject: [Koha] MySQL and foreign keys Last night I attended a PerlMongers group meeting here in Oakland, CA and one of the presenters at the meeting asserted that MySQL could not claim to be a completely relational database because it doesn't let you define foreign keys. As a result, he feels that MySQL fails the ACID test (atomicity, consistency, referential integrity, and durability), and he advised people to avoid using it in Perl applications and instead use Postgres or some other relational database with more stability. He cited an example where you might have a one-to-one relationship between primary key values in two tables and if you deleted a value from one of the tables, MySQL would leave that value in the other table as dangling data without warning you to take care of it and as a result really mess up your database. Can anyone on the Koha list comment on this assertion and what the consequences might be for Koha? ____________________________________________________________________ CAUTION - This message may contain privileged and confidential information intended only for the use of the addressee named above. If you are not the intended recipient of this message you are hereby notified that any use, dissemination, distribution or reproduction of this message is prohibited. If you have received this message in error please notify Safe Air Ltd immediately. Any views expressed in this message are those of the individual sender and may not necessarily reflect the views of Safe Air. _____________________________________________________________________ For more information on the Safe Air Group, visit us online at http://www.safeair.co.nz/ _____________________________________________________________________

4 3

Problems modifying a new record
by Jim Thomas 16 Jan '03

16 Jan '03

Hi all, We have recently installed Koha at our school, and today our librarian ran into some trouble when she tried to modify a new entry. This server is not available on the internet except via ssh (text mode). I poked around the database using mysql after she reported this problem: ============================================================================== I used the marc lookup and imported the file for Charlie Horse/Mrs. White's Secret Sock. I modified the data before saving. It set up the biblio for the book, plus my item number 5658. Then I later realized that I wanted to add one more subject to the subject listing. I looked up Charlie Horse in the catalog. I clicked on it which gave me the Biblio. I clicked on modify. Even though the biblio showed subject lines, the subject lines were missing on the modify screen! I input the one it wanted to add and clicked the query(save) button. Normally it flips me to the new modified biblio, but this time it only brought up a blank biblio. I again looked up Charlie Horse in the catalog. This time before trying to add the new subject, I realized that when I added it to the catalog in the first place I caused an accidental mispelling to the title. I tried to fix that only, but with no more success than when I had tried to add the subject line. Finally I decided that I would delete the entire thing and start again. I had to first delete my item number 5658. Then I deleted the biblio. At that point both the book title and item number no longer showed up when I searched the catalog. So I assumed everything had been erased out and went to start all over again on the book. But the computer would act like the biblio was already there and prompt me for an item number. It would act like it was taking the item number -- no error messages or warnings that the number was already in use. But then when I would look up Charlie Horse, the title was there but it refused to say that there was an item in the library. ============================================================================== I don't really know my way around in MySQL - just enough to be dangerous. And I really don't know how the db is laid our in Koha. Here's what I found/did. I found that the original biblionumber for the "Charlie Horse" book was 934, and the new one had a biblionumber of 940. biblioitems and bibliosubject both still had entries for biblionumber 934, which I deleted. The items table still had an entry for biblionumber="934", but no entry for biblionumber="940". So I did an update items set biblionumber = "940" where barcode="5658"; Which seemed to partially fix the problem. After I did this, she tried to do a dummy checkout of the book, but it couldn't find it. Can anyone advise me at this point? Are there other tables I need to modify? Should I refrain from manipulating the db with mysql (yes)? -- Jim Thomas Principal Applications Engineer Bittware, Inc jthomas(a)bittware.com http://www.bittware.com (703) 779-7770 I thought I was wrong once, but I was mistaken.

4 8

MySQL and foreign keys
by Larry Currie 16 Jan '03

16 Jan '03

Last night I attended a PerlMongers group meeting here in Oakland, CA and one of the presenters at the meeting asserted that MySQL could not claim to be a completely relational database because it doesn't let you define foreign keys. As a result, he feels that MySQL fails the ACID test (atomicity, consistency, referential integrity, and durability), and he advised people to avoid using it in Perl applications and instead use Postgres or some other relational database with more stability. He cited an example where you might have a one-to-one relationship between primary key values in two tables and if you deleted a value from one of the tables, MySQL would leave that value in the other table as dangling data without warning you to take care of it and as a result really mess up your database. Can anyone on the Koha list comment on this assertion and what the consequences might be for Koha? Larry Currie -- Lawrence W. Currie User Services Librarian California Academy of Sciences Golden Gate Park San Francisco, CA 94118 lcurrie(a)calacademy.org (415) 750-7108 (415) 750-7106 fax http://www.calacademy.org/research/library/

4 7