At 03:38 PM 11/29/2010 -0500, Chris Nighswonger wrote:
On Mon, Nov 29, 2010 at 3:31 PM, Owen Leonard <<mailto:oleonard@myacpl.org>oleonard@myacpl.org> wrote: ... The bad news is you'll still have to update your spreadsheets to replace phrases like "marine biology" with a corresponding less-than-10-letter code.
The not-so-bad-news is that you could whip up a Perl script to parse through your spreadsheets and add the additional column along with populating it properly.
and Susan Bennett added
I may be wrong, so anyone out there with more knowledge please correct, but I don't think you can use spaces in the ccode so changing the length wont help. Can't you do a simple find and replace?
First, are spaces allowed in the 10 character CCODE? Are there any other restrictions (numerics, underlines, hyphens, etc)? I find nothing (easily) in the documentation. As a comparison, the LOC code allows 80 characters including (at least) spaces. For various historical reasons we have nearly two hundred "categories" spread across 468 spreadsheets - that would be a possible 100,000 "simple search and replace" operations ;={ and I've never had much success with Perl looking for entries in a specific column of a spreadsheet where obviously the "category name" could also appear in the title, keywords and reviews which we obviously do not want to modify. So I'll probably end up attempting to modify the SQL parameter for field length (a task which, from past experience with Oracle, I am not looking forward to.) This is the first major hiccough we have encountered with the data migration and at the moment is a show-blocker. Thanks to you all - all suggestions, etc are warmly welcomed. Paul
2010/11/29 Paul <paul.a@aandc.org>
First, are spaces allowed in the 10 character CCODE? Are there any other restrictions (numerics, underlines, hyphens, etc)? I find nothing (easily) in the documentation. As a comparison, the LOC code allows 80 characters including (at least) spaces.
It appears that you can, at least, define a CCODE type with spaces. Whether it works in practice or not I don't know.
For various historical reasons we have nearly two hundred "categories" spread across 468 spreadsheets - that would be a possible 100,000 "simple search and replace" operations ;={ and I've never had much success with Perl looking for entries in a specific column of a spreadsheet where obviously the "category name" could also appear in the title, keywords and reviews which we obviously do not want to modify.
We use Text::CSV in a number of places in Koha to work with comma delimited files, and it works very nicely. I don't see why you should have any problem munging up 468 spreadsheets using that module. But then, maybe I'm being naive here. :-)
So I'll probably end up attempting to modify the SQL parameter for field length (a task which, from past experience with Oracle, I am not looking forward to.)
This will probably break things at worst and at best is ill advised. It will definitely result in complications during future upgrades should the core code change in the future. Custom code hacks (especially of this nature) are not recommended for the sake of future sanity and happiness. Kind Regards, Chris
Le 29/11/2010 22:49, Chris Nighswonger a écrit :
2010/11/29 Paul <paul.a@aandc.org <mailto:paul.a@aandc.org>>
First, are spaces allowed in the 10 character CCODE? Are there any other restrictions (numerics, underlines, hyphens, etc)? I find nothing (easily) in the documentation. As a comparison, the LOC code allows 80 characters including (at least) spaces.
It appears that you can, at least, define a CCODE type with spaces. Whether it works in practice or not I don't know.
For various historical reasons we have nearly two hundred "categories" spread across 468 spreadsheets - that would be a possible 100,000 "simple search and replace" operations ;={ and I've never had much success with Perl looking for entries in a specific column of a spreadsheet where obviously the "category name" could also appear in the title, keywords and reviews which we obviously do not want to modify.
We use Text::CSV in a number of places in Koha to work with comma delimited files, and it works very nicely. I don't see why you should have any problem munging up 468 spreadsheets using that module. But then, maybe I'm being naive here. :-) Or SpreadSheet::ParseExcel Or DBD::Excel Or even use Excel formulas... depending on how efficient you are in either of the languages and the time you may have to spend on that.
So I'll probably end up attempting to modify the SQL parameter for field length (a task which, from past experience with Oracle, I am not looking forward to.)
This will probably break things at worst and at best is ill advised. It will definitely result in complications during future upgrades should the core code change in the future.
This would also be my advice too. Problem is that ccode ans its length is used in many tables (circulation rules for instance.) So I would not go that way. -- Henri-Damien LAURENT
Perhaps this is a bug, or at least an inconsistency between the items, and authorised_values SQL table schema. Koha allows you to define an authorised value having length 80, but then you can't use it. Here is why: The SQL field items.ccode is a varchar(10). The SQL field authorised_values.authorised_value is a varchar(80). If this is a bug, how can I go about opening a defect? Thanks, Pete. -- View this message in context: http://koha.1045719.n5.nabble.com/SQL-field-lengths-tp3285076p3286344.html Sent from the Koha - Discuss mailing list archive at Nabble.com.
Pete, You can report this issue to http://bugs.koha-community.org. I've checked, and there doesn't seem to be an existing report. -Ian On Tue, Nov 30, 2010 at 11:47 AM, Peter Huerter <pete.huerter@gmail.com>wrote:
Perhaps this is a bug, or at least an inconsistency between the items, and authorised_values SQL table schema.
Koha allows you to define an authorised value having length 80, but then you can't use it.
Here is why:
The SQL field items.ccode is a varchar(10).
The SQL field authorised_values.authorised_value is a varchar(80).
If this is a bug, how can I go about opening a defect?
Thanks,
Pete. -- View this message in context: http://koha.1045719.n5.nabble.com/SQL-field-lengths-tp3285076p3286344.html Sent from the Koha - Discuss mailing list archive at Nabble.com. _______________________________________________ Koha mailing list http://koha-community.org Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Ian Walls Lead Development Specialist ByWater Solutions Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
Filed as bug 5458. http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5458 Thanks Ian, Pete. -- View this message in context: http://koha.1045719.n5.nabble.com/SQL-field-lengths-tp3285076p3286439.html Sent from the Koha - Discuss mailing list archive at Nabble.com.
Spaces are allowed in authorised values and work in practice. Special characters like '/' do not seem to work in practice. My CCODEs and LOCs that have spaces in them are properly mapped in the OPAC user interface description of a book. The authorised value contains spaces but are accurately mapped to the corresponding description string. The same is not true for special characters. The same test fails. Pete. -- View this message in context: http://koha.1045719.n5.nabble.com/SQL-field-lengths-tp3285076p3286353.html Sent from the Koha - Discuss mailing list archive at Nabble.com.
participants (5)
-
Chris Nighswonger -
Ian Walls -
LAURENT Henri-Damien -
Paul -
Peter Huerter