* Fridolyn SOMERS ([email protected]) wrote: > Hie, > > I see what you meen. > > But has far as I know, the link between biblio and authorities is not > managed during import (it would be quite difficult I think). > Subfield 700$9 is considered as a normal data. > > You may find a script in Koha to synchronise the biblio fields with the > existing authorities. > If not, you'll have to create it. Maybe a SQL script is enought. > > Tell us if you suceed.
Hi All There is a script in misc link_bibs_to_authorities.pl which should create the linkages for you Chris > > Best regards, > > 2011/2/15 Fr�re S�bastien <[1][email protected]> > > Hello, > > As we obtain no reply for an inconsistent database, I will explain again > the problem, with SQL for examples. > > Currently, after using imported set of notices and using it we have the > following results: > > SELECT count(*) > �FROM biblioitems > �WHERE extractvalue(biblioitems.marcxml, > '/record/datafield[@tag="700"]/subfield[@code="9"]') != '' > � AND extractvalue(biblioitems.marcxml, > '/record/datafield[@tag="700"]/subfield[@code="9"]') NOT IN ( > � �SELECT authid FROM auth_header ); > +----------+ > | count(*) | > +----------+ > | � � �121 | > +----------+ > > english-version: If I extract from MarcXML (on table biblioitems) the > 700.9 (Primary Author, koha_internal_code) and search in auth_header, we > currently have 121 items with no-existent 700.9 . > > This is only a part of the problem: some 700.9 are existent but wrong > (points to bad authority). > > SELECT count(*) > �FROM biblioitems, auth_header > �WHERE extractvalue(biblioitems.marcxml, > '/record/datafield[@tag="700"]/subfield[@code="9"]') = > auth_header.authid > � AND extractvalue(biblioitems.marcxml, > '/record/datafield[@tag="700"]/subfield[@code="a"]') != > extractvalue(auth_header.marcxml, > '/record/datafield[@tag="200"]/subfield[@code="a"]'); > +----------+ > | count(*) | > +----------+ > | � � � �3 | > +----------+ > > Any suggestions ? This seems a bug (in import of notices where old > koha_internal_code is not removed), but I would prefered have your > opinion before submit a bugreport. > > And I will like some clues to correct the inconsitences ! > Thanks. > > -- > Fr�re S�bastien Marie > Abbaye Notre Dame de La Trappe > 61380 Soligny-la-Trappe > T�l: 02.33.84.17.00 > Fax: 02.33.34.98.57 > Web: [2]http://www.latrappe.fr/ > > On Sat, Jan 29, 2011 at 12:13:28PM +0100, Fr�re S�bastien Marie wrote: > > Hello, > > > > Recently, we have imported a set of notices, from another abbey, in > > the reservoir. > > > > When we create a new examplar using the previous imported notices, > > the field 700.9 (authority - internal koha number) refering the > > auth_id isn't updated or removed (still reference the old authority > > number, in the other catalog). > > > > As result, we have an examplar with 700.a (authority name) correct, > > but with an internal reference wrong (not valid in us catalog). > > > > If we search all notices linked with an authority, there is wrong > > attribution. > > > > Next an example. > > > > Starting with: > > �- Notices in reservoir: > > � �- Title_A / Author_A (auth_id = 1) [from import] > > > > �- Authority in catalog: > > � �- Author_B (auth_id = 1) [created locally] > > > > �- Notice in catalog: > > � �- Title_B / Author_B (auth_id = 1) > > > > > > Next, we create a new examplar based on notice in reservoir, result: > > �- Authority in catalog: > > � �- Author_B (auth_id = 1) [created locally] > > > > �- Notice in catalog: > > � �- Title_A / Author_A (auth_id = 1) > > � �- Title_B / Author_B (auth_id = 1) > > > > (doubt if Author_A added in authorities or not) > > > > Now, if search notice attached with Author_B (auth_id = 1): > > �results: > > � - Title_A / Author_A (auth_id = 1) > > � - Title_B / Author_B (auth_id = 1) > > > > The database is inconsistent. > > > > Where is the problem: > > �- a misused of imported MARC: an option somewhere should be set... > > �- a bug in importing MARC: 700.9 should be cleaned before import... > > �- another possibility ? > > > > Currently, no bug report filled, as I don't no if it is a misusing > > or a bug. > > > > Thanks. > > -- > > Fr�re S�bastien Marie > > Abbaye Notre Dame de La Trappe > > 61380 Soligny-la-Trappe > > T�l: 02.33.84.17.00 > > Fax: 02.33.34.98.57 > > Web: [3]http://www.latrappe.fr/ > _______________________________________________ > Koha-devel mailing list > [4][email protected] > [5]http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : [6]http://www.koha-community.org/ > git : [7]http://git.koha-community.org/ > bugs : [8]http://bugs.koha-community.org/ > > -- > Fridolyn SOMERS > ICT engineer > PROGILONE - Lyon - France > [9][email protected] > > References > > Visible links > 1. mailto:[email protected] > 2. http://www.latrappe.fr/ > 3. http://www.latrappe.fr/ > 4. mailto:[email protected] > 5. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > 6. http://www.koha-community.org/ > 7. http://git.koha-community.org/ > 8. http://bugs.koha-community.org/ > 9. mailto:[email protected] > _______________________________________________ > Koha-devel mailing list > [email protected] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ -- Chris Cormack Catalyst IT Ltd. +64 4 803 2238 PO Box 11-053, Manners St, Wellington 6142, New Zealand
signature.asc
Description: Digital signature
_______________________________________________ Koha-devel mailing list [email protected] http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
