Hi, I quickly copied 952k to 952o directly in Koha 229's database via sql*, exported, imported with bulkimport.pl - and the item callnumbers show up on the biblio detail page (/cgi-bin/koha/catalogue/detail.pl?biblio=XYZ) for all the books, but only for some books on the search results page (/cgi-bin/koha/catalogue/search.pl?q=QUERY). Under /cgi-bin/koha/catalogue/moredetail.pl for either book (showing under search results or not), I see no difference. Although, I did note that the item-type and home-branch are not correctly set, but that's true for for all of the books. Editing the item, setting it to a valid item-type didn't fix the display issue. In fact, editing the items for any book, I can't see any difference (the same fields are set, and in the same fashion). So, my question becomes: what could cause the call number to show up within the biblio details, but not on the search results page (something within the biblio structure? Although, here I see both have 082a set correctly...)? Any thoughts would be welcome, Andrew * DELETE FROM marc_subfield_table where tag = '952' and subfieldcode = 'o'; INSERT INTO marc_subfield_table (...) SELECT ...,'o',... WHERE tag = '952' and subfieldcode = 'k'; This does not properly fix however the tagorder field, which ends up duplicated. I hope it's only used in "order by" clauses and not internally otherwise within Koha - the export seems to have worked properly and marcedit shows both 952k and 952o tags per book. On Sat, Aug 15, 2009 at 9:10 PM, Andrew Séguin<aseguo@gmail.com> wrote:
I'm trying to do the migration from Koha 229 to Koha 30, and haven't yet experienced full success.
First, upgrading in place didn't work out so well for some reason - I had copied the virtual machine's disk, so was able to revert quickly. After looking through the mailing lis, I then tried just running a Koha 30 system; imported the database of the 229 system and ran the upgrade scripts... this also didn't work out so well, "lazy me" just moved on once again. Finally, I took a koha 30 prebuilt virtual machine (time constraints, surely not because I'm a "lazy" system admin, right?) and imported the bibliographic entries.
Through the web interface, it worked so-so, rejecting some "slices" (read: independent files with 1000 exported records from the 229 system) of the exported data... tried the bulkimport.pl script which rejected certain records as bad marc ... which I took (combined with some combing of the mail-group archives) as the reason behind the failure of the web interface. In the end, imported by the web interface or bulkimport.pl, I would end up with some biblios with the items all proper, some with the items not showing up properly (without call number).
The Koha 30 system I'm using is the pre-built virtualbox machine 3.0 release -- version "Koha 3.0001005". Before running bulkimport, I recreated the same item-types and branches. Both systems are set to MARC21.
I'm turning to the community here for some advice how to proceed / what to consider (I'm not afraid of research, scripting, or SQL... but a bit lost at the moment):
* My first question would be, is there any trick, quick way, of knowing which biblios were rejected by bulkimport.pl ? I tried with "-v", "-v 2" without success to get more details. (sample/full command: nohup /home/koha/kohaclone/misc/migration_tools/bulkmarcimport.pl -d -v 2 -file ~/Koha20090811_02.mrc -commit 1 | tee ~/bulkimport_KOP20090811_2.log after having set PERL5LIB and KOHA_CONF)
* My second question, is - are there any pointers/ideas concerning the import of items?
Items that I consider properly imported have the call number displayed; where not, the call number is missing. In either case at least the barcode is correctly imported. Maybe somebody has a quick moment to look at the difference between the two and sees something obvious I don't? * Imported correctly: http://161.53.212.104/cgi-bin/koha/opac-detail.pl?biblionumber=820 * Not imported correctly: http://161.53.212.104/cgi-bin/koha/opac-detail.pl?biblionumber=9880 (was biblio 11874)
I just (while writing this mail) found a difference looking at the records from Koha 229 and Koha 30: bibid 820 had under Koha 229 the "call number prefix" set to the same value as "call number" where 9880 doesn't. Maybe somebody has a comment about this (did I ignore something basic with the frameworks)? - I'll test the call number / call number prefix issue (either with marc-edit or directly in 229's database, for each item, copying the call-number to the call-number-prefix subfield value ...) within a day or two...
Many thanks for all those in general who take the time work on Koha, even more to those who patiently read this entire email!
Andrew