[Koha] MySQL and year published

Marcel de Rooy M.de.Rooy at rijksmuseum.nl
Mon Dec 10 20:33:08 NZDT 2012

It is saved in two places: MARC 260c and the first year goes additionally to the Koha field as defined in marc_subfield_structure (kohafield). 
See the logic in Biblio.pm; search on copyrightdate. 


-----Oorspronkelijk bericht-----
Van: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz] Namens Paul
Verzonden: zondag 9 december 2012 23:40
Aan: koha at lists.katipo.co.nz
Onderwerp: [Koha] MySQL and year published

In all our frameworks we use 260$c for "date of publication" (mandatory -- even to the point of "not known / n.k." so the field cannot be NULL.)

However, 260$c appears to be saved EITHER as biblioitems.publicationyear OR as biblio.copyrightdate and we do not have any records at all that include both; hence reports have to use e.g.

IFNULL (biblio.copyrightdate,biblioitems.publicationyear) AS Year,

I get the impression (but am far from certain) that biblioitems.publicationyear was used in Koha 3.6 and biblio.copyrightdate is used in 3.8

Maybe one of you who was involved in the "update data tables" scripts (which I have always found to work satisfactorily) could help me?  Is there any reason not to copy publicationyear to the copyrightdate? Is biblioitems.publicationyear still used in 3.8? SchemaSpy does not appear to answer this question (although publication year is given as text, 65535; copyrightdate as smallint, 5) and while the data transfer went well in my sandbox, I hesitate to do this in production in case there are side effects.

The reason for my doubts is that a smallint should not be able to save e.g. 
" [c1974?] " but Koha does save it while MySQL reports purely 1974 ... so where is the "text" saved?

Many thanks and best regards,

Koha mailing list  http://koha-community.org Koha at lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha

More information about the Koha mailing list