Larry Currie wrote:

I hoping that within a couple of days we will have the item data for our collections loaded into the 945, 946, and 949 fields of our MARC records, and then we would like to run a Perl script which will go through each of our MARC records and extract and insert into the Koha MySQL tables biblio, biblioitems, and items all of the data needed to run version 1.9.0. Has anyone developed such a script at this point or give me an idea of what the commands would look like to accomplish this?

Larry Currie

C4/Biblio.pm is your friend in this matter : =item (oldbibnum,$oldbibitemnum) = NEWnewbibilio($dbh,$MARCRecord,$oldbiblio,$oldbiblioitem); creates a new biblio from a MARC::Record. The 3rd and 4th parameter are hashes and may be ignored. If only 2 params are passed to the sub, the old-db hashes are builded from the MARC::Record. If they are passed, they are used. =item NEWnewitem($dbh, $record,$bibid); adds an item in the db. Some explanations : * load your MARC data with a MARC::Record * open a db handler * call NEWnewbiblio($dbh,$MARCrecord) to add a biblio. IF you plan to load biblio AND item in the same MARC Record : * remember that all item fields MUST be in the same tag (995 proposed) * split the MARC record in 2 parts : one with biblio and one with item * call NEWnewbiblio and NEWnewitem hope it will work fine. If you write such a script, please submit it in cvs, it should be useful for 2.0 version (migrating from another ILS) Comments from Biblio.pm ======================================================================== move from 1.2 to 1.4 version : 1.2 and previous version uses a specific API to manage biblios. This API uses old-DB style parameters. In the 1.4 version, we want to do 2 differents things : - keep populating the old-DB, that has a LOT less datas than MARC - populate the MARC-DB To populate the DBs we have 2 differents sources : - the standard acquisition system (through book sellers), that does'nt use MARC data - the MARC acquisition system, that uses MARC data. Thus, we have 2 differents cases : - with the standard acquisition system, we have non MARC data and want to populate old-DB and MARC-DB, knowing it's an incomplete MARC-record - with the MARC acquisition system, we have MARC datas, and want to loose nothing in MARC-DB. So, we can't store datas in old-DB, then copy in MARC-DB. we MUST have an API for true MARC data, that populate MARC-DB then old-DB That's why we need 4 subs : all I<subs beginning by MARC> manage only MARC tables. They manage MARC-DB with MARC::Record parameters all I<subs beginning by OLD> manage only OLD-DB tables. They manage old-DB with old-DB parameters all I<subs beginning by NEW> manage both OLD-DB and MARC tables. They use MARC::Record as parameters. it's the API that MUST be used in MARC acquisition system all I<subs beginning by seomething else> are the old-style API. They use old-DB as parameter, then call internally the OLD and MARC subs. - NEW and old-style API should be used in koha to manage biblio - MARCsubs are divided in 2 parts : * some of them manage MARC parameters. They are heavily used in koha. * some of them manage MARC biblio : they are mostly used by NEW and old-style subs. - OLD are used internally only all subs requires/use $dbh as 1st parameter. -- Paul POULAIN Consultant indépendant en logiciels libres responsable francophone de koha (SIGB libre http://www.koha-fr.org)