Time Nick Message 14:28 thd paul_away: thank you, thank you very much, and pleasant dreams :) 14:19 paul ok,l eaving now, time to go to bed (TGV at 5AM next morning...) 14:19 paul (i'm migrating a library with very complete/complex record, and they saw the problem. That's fixed now in CVS, will be in 2.2.4) 14:18 paul as 95% of the time & with simple MARC record the order is alphabetical, nobody saw the bug until now 14:18 paul the subfieldorder field was managed by MARC editor, but ignored when the record was retrieved. 14:17 paul thd : MARCgetbiblio is used by everybody that has Koha. In 2.2.3 & previous versions, subfields where ordered automatically alphabetically, even if in the DB they had a different order. 14:03 kados but I think you're right 13:58 thd owen: Being at NPL, you should also be able to guess better :) 13:55 thd owen: second hand is better than my just guessing :-) 13:54 owen I think maybe they do some of each, but that's second-hand. 13:54 thd owen: thanks 13:54 owen I'm guessing they either edit instead from within Koha or they edit the stored record in their MARC editor and re-load it into Koha 13:53 thd kados: Does the cataloguer just use the Koha built in MARC editor at that point? 13:52 thd kados: What happens at NPL when a cataloguer wants to edit an already existing record in Koha using ITS.MARC for Windows? 13:48 thd kados: So bulkmarcimport.pl seems to import all fields in all records except the leader. The leader should be stored as 000. 13:45 thd kados: The MARC file was being read as a perl script with the debug option set in that instance :-) 13:43 thd kados: bulkmarcimport.pl does work when it is not being specified as an additional include directory, as I had done carelessly from the -I perl command line switch earlier last night :) 13:30 kados thx ... 13:29 owen wb kados 12:36 thd paul: ping 12:06 thd You have MARCgetbiblio using it now on your machine but not elsewhere? 12:03 paul it's just MARCgetbiblio that didn't use it due to the bug 12:02 paul around 2 years ago ;-)