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. Marcel -----Oorspronkelijk bericht----- Van: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] Namens Paul Verzonden: zondag 9 december 2012 23:40 Aan: koha@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. SELECT 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, Paul _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha