* Fridolyn SOMERS (fridolyn.somers@gmail.com) 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]semarie-koha@latrappe.fr>
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]Koha-devel@lists.koha-community.org [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]fridolyn.somers@gmail.com
References
Visible links 1. mailto:semarie-koha@latrappe.fr 2. http://www.latrappe.fr/ 3. http://www.latrappe.fr/ 4. mailto:Koha-devel@lists.koha-community.org 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:fridolyn.somers@gmail.com
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org 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