Good afternoon all. Brief History for that have not seen my other posts. We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found. I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn't finding it in the DB. We have found that the DB is pretty much set to latin1 as the character set but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue. I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue. If anyone has seen this before please let me know your thoughts. Thanks Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?"
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure. We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data. --Joe
Joe I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found 2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us> Good afternoon all. Brief History for that have not seen my other posts. We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found. I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB. Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure. We have found that the DB is pretty much set to latin1 as the character set What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1? but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue. It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't). I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue. If anyone has seen this before please let me know your thoughts. This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data. --Joe
I wouldn't worry so much about what's in Follett. I'd even wager that the barcodes are actually like that in Follett, but it doesn't show them that way. What I would do is figure out how the barcode is where it's on the book, and make sure Koha matches that. Other than that, As I understand it the Follett BarcodeInputFilter will remove the leading 0's and add the space. On Tue, 2009-04-07 at 14:55 -0400, Roche III, Edward wrote:
Joe
I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created?
Thanks!
Ed
Edward J. Roche
Network Administrator
Solanco School District
717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure.
We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data.
--Joe
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
I did a couple test scans of the barcodes labels into a test editor and it is reading what is on the label which is no zeros and a space. I will recreate the DB and see what it does. Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Michael Hafen [mailto:mdhafen@tech.washk12.org] Sent: Tuesday, April 07, 2009 2:57 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found I wouldn't worry so much about what's in Follett. I'd even wager that the barcodes are actually like that in Follett, but it doesn't show them that way. What I would do is figure out how the barcode is where it's on the book, and make sure Koha matches that. Other than that, As I understand it the Follett BarcodeInputFilter will remove the leading 0's and add the space. On Tue, 2009-04-07 at 14:55 -0400, Roche III, Edward wrote:
Joe
I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created?
Thanks!
Ed
Edward J. Roche
Network Administrator
Solanco School District
717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure.
We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data.
--Joe
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
It works now. I guess I was so caught up in the barcodes in Koha matching the barcodes on the books I never really gave the T-prefix a second look. Thank you all that have helped me with this issue!!!!!! Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Michael Hafen [mailto:mdhafen@tech.washk12.org] Sent: Tuesday, April 07, 2009 2:57 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found I wouldn't worry so much about what's in Follett. I'd even wager that the barcodes are actually like that in Follett, but it doesn't show them that way. What I would do is figure out how the barcode is where it's on the book, and make sure Koha matches that. Other than that, As I understand it the Follett BarcodeInputFilter will remove the leading 0's and add the space. On Tue, 2009-04-07 at 14:55 -0400, Roche III, Edward wrote:
Joe
I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created?
Thanks!
Ed
Edward J. Roche
Network Administrator
Solanco School District
717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure.
We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data.
--Joe
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
Not sure if anyone remembers this issue I had a couple month ago so I attached one of the email chains with Mike Hafen about it. At the time I was trying to get Koha to recognize the barcodes that were exported out of Follett but I was trying to match what was actually on the book barcodes instead of just letting them be and was well. Here is my current issue with the is. We currently have 7 separate catalogs for 7 different building and we will be moving to one big one as we migrate the building to Koha. Now after meeting with our librarians, we have found that number of items have over lapping barcode so we decided it will be easier to re-barcode then to try and replace the duplicates. So our barcodes are now (2) letters + a 6 digit number (ex: SM556471). So my question is what is the right "itemBarcodeInputFilter"? If I set it to T-prefix, Cuecat or Whitespace I get barcode not found and if I set it to none (which was something we tried with the last issue it gives me a blank screen. I have run the rebuild_zebra.pl and the sync_items_in_marc_bib.pl scripts. Am I missing a step? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Michael Hafen [mailto:mdhafen@tech.washk12.org] Sent: Tuesday, April 07, 2009 2:57 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found I wouldn't worry so much about what's in Follett. I'd even wager that the barcodes are actually like that in Follett, but it doesn't show them that way. What I would do is figure out how the barcode is where it's on the book, and make sure Koha matches that. Other than that, As I understand it the Follett BarcodeInputFilter will remove the leading 0's and add the space. On Tue, 2009-04-07 at 14:55 -0400, Roche III, Edward wrote:
Joe
I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created?
Thanks!
Ed
Edward J. Roche
Network Administrator
Solanco School District
717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure.
We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data.
--Joe
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha
This is a tough issue, and one that I went through when I looked at adding a second library to my Koha install years ago. My solution then, and now, was to change Koha to handle having overlapping barcodes. It's not a good solution, but to us re-barcoding was out of the question. The bulk of the change is making sure any time a book is looked up in Koha by it's barcode the users branch is also used. This is best suited to the IndependantBranches System Preference being on, as the behavior of the two are complementary. On Thu, 2009-06-18 at 09:19 -0400, Roche III, Edward wrote:
Not sure if anyone remembers this issue I had a couple month ago so I attached one of the email chains with Mike Hafen about it. At the time I was trying to get Koha to recognize the barcodes that were exported out of Follett but I was trying to match what was actually on the book barcodes instead of just letting them be and was well.
Here is my current issue with the is. We currently have 7 separate catalogs for 7 different building and we will be moving to one big one as we migrate the building to Koha. Now after meeting with our librarians, we have found that number of items have over lapping barcode so we decided it will be easier to re-barcode then to try and replace the duplicates. So our barcodes are now (2) letters + a 6 digit number (ex: SM556471). So my question is what is the right "itemBarcodeInputFilter"? If I set it to T-prefix, Cuecat or Whitespace I get barcode not found and if I set it to none (which was something we tried with the last issue it gives me a blank screen.
I have run the rebuild_zebra.pl and the sync_items_in_marc_bib.pl scripts. Am I missing a step?
Thanks! Ed
Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
-----Original Message----- From: Michael Hafen [mailto:mdhafen@tech.washk12.org] Sent: Tuesday, April 07, 2009 2:57 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
I wouldn't worry so much about what's in Follett. I'd even wager that the barcodes are actually like that in Follett, but it doesn't show them that way.
What I would do is figure out how the barcode is where it's on the book, and make sure Koha matches that.
Other than that, As I understand it the Follett BarcodeInputFilter will remove the leading 0's and add the space.
On Tue, 2009-04-07 at 14:55 -0400, Roche III, Edward wrote:
Joe
I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created?
Thanks!
Ed
Edward J. Roche
Network Administrator
Solanco School District
717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure.
We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data.
--Joe
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://development.washk12.org/gitweb/ or git://development.washk12.org/koha
I have now tried to clear the itemBarcodeInputFilter field so that there was no value selected and I still get the error "Barcode Not Found". I don't know if it is a filter issue or a querying issue. I am not doing anything special with the barcode. Anyone have any ideas? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Roche III, Edward Sent: Thursday, June 18, 2009 9:19 AM To: koha-devel Subject: Re: [Koha-devel] Barcode Not Found Not sure if anyone remembers this issue I had a couple month ago so I attached one of the email chains with Mike Hafen about it. At the time I was trying to get Koha to recognize the barcodes that were exported out of Follett but I was trying to match what was actually on the book barcodes instead of just letting them be and was well. Here is my current issue with the is. We currently have 7 separate catalogs for 7 different building and we will be moving to one big one as we migrate the building to Koha. Now after meeting with our librarians, we have found that number of items have over lapping barcode so we decided it will be easier to re-barcode then to try and replace the duplicates. So our barcodes are now (2) letters + a 6 digit number (ex: SM556471). So my question is what is the right "itemBarcodeInputFilter"? If I set it to T-prefix, Cuecat or Whitespace I get barcode not found and if I set it to none (which was something we tried with the last issue it gives me a blank screen. I have run the rebuild_zebra.pl and the sync_items_in_marc_bib.pl scripts. Am I missing a step? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Michael Hafen [mailto:mdhafen@tech.washk12.org] Sent: Tuesday, April 07, 2009 2:57 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found I wouldn't worry so much about what's in Follett. I'd even wager that the barcodes are actually like that in Follett, but it doesn't show them that way. What I would do is figure out how the barcode is where it's on the book, and make sure Koha matches that. Other than that, As I understand it the Follett BarcodeInputFilter will remove the leading 0's and add the space. On Tue, 2009-04-07 at 14:55 -0400, Roche III, Edward wrote:
Joe
I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created?
Thanks!
Ed
Edward J. Roche
Network Administrator
Solanco School District
717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure.
We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data.
--Joe
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
OK...now I opened a item record (through Webmin)like I was going to edit it didn't change anything then saved the record and now I can enter that barcode and it will allow me to check it out with no error. These barcodes were import into a temp table then I ran a UPDATE sql statement to update the barcodes in the item table from the temp table. Can anyone think of a reason why the system will not find the barcode unless I open and save the record first? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Roche III, Edward Sent: Monday, June 22, 2009 10:55 AM To: koha-devel Subject: Re: [Koha-devel] Barcode Not Found I have now tried to clear the itemBarcodeInputFilter field so that there was no value selected and I still get the error "Barcode Not Found". I don't know if it is a filter issue or a querying issue. I am not doing anything special with the barcode. Anyone have any ideas? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Roche III, Edward Sent: Thursday, June 18, 2009 9:19 AM To: koha-devel Subject: Re: [Koha-devel] Barcode Not Found Not sure if anyone remembers this issue I had a couple month ago so I attached one of the email chains with Mike Hafen about it. At the time I was trying to get Koha to recognize the barcodes that were exported out of Follett but I was trying to match what was actually on the book barcodes instead of just letting them be and was well. Here is my current issue with the is. We currently have 7 separate catalogs for 7 different building and we will be moving to one big one as we migrate the building to Koha. Now after meeting with our librarians, we have found that number of items have over lapping barcode so we decided it will be easier to re-barcode then to try and replace the duplicates. So our barcodes are now (2) letters + a 6 digit number (ex: SM556471). So my question is what is the right "itemBarcodeInputFilter"? If I set it to T-prefix, Cuecat or Whitespace I get barcode not found and if I set it to none (which was something we tried with the last issue it gives me a blank screen. I have run the rebuild_zebra.pl and the sync_items_in_marc_bib.pl scripts. Am I missing a step? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Michael Hafen [mailto:mdhafen@tech.washk12.org] Sent: Tuesday, April 07, 2009 2:57 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found I wouldn't worry so much about what's in Follett. I'd even wager that the barcodes are actually like that in Follett, but it doesn't show them that way. What I would do is figure out how the barcode is where it's on the book, and make sure Koha matches that. Other than that, As I understand it the Follett BarcodeInputFilter will remove the leading 0's and add the space. On Tue, 2009-04-07 at 14:55 -0400, Roche III, Edward wrote:
Joe
I have reworked the barcodes in Koha because the barcodes Follett spits out in the export do not match what is actually in Follett. Will the T-Prefix remove the 2 zeros and add a space to match the barcode labels that Follett created?
Thanks!
Ed
Edward J. Roche
Network Administrator
Solanco School District
717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
From: Joe Atzberger [mailto:ohiocore@gmail.com] Sent: Monday, April 06, 2009 5:35 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
2009/4/6 Roche III, Edward <edward_roche@solanco.k12.pa.us>
Good afternoon all.
Brief History for that have not seen my other posts.
We are trying to migrate to Koha from Follett, when biblio info is exported from Follett the barcodes have zeros add in place of a space, T 12345 comes out as T0012345. I updated my records and re-import the barcode field and but when I try to check out a book it tells me barcode not found.
I have be trying some different thing with Mike Hafen. We have come to find that Koha is reading the barcode correctly but just isn’t finding it in the DB.
Do you have syspref "itemBarcodeInputFilter" set? The T-Prefix setting was designed for migrating Follett libraries without changing their barcodes. If you have now reworked your data and still are filtering the barcodes, then that would predict failure.
We have found that the DB is pretty much set to latin1 as the character set
What does that mean? The intent of the encoding_scratchpad part of Koha setup is to get all Koha's internal DB settings to UTF-8. What makes you think anything is latin1?
but when I created the DB I select UTF-8 and I also converted the export data from Follett to UTF-8. Do I need to change the char set for the whole MySQL or is that a non-issue.
It's a non-issue because none of your barcodes have characters that would be represented any differently in UTF8 than they are in latin1 (unless you care about the binary level, and we don't).
I really have like this product but out librarians have said they will not re-barcode because on average they have 16k+ items that they would have to change. I am at wits end with this issue and I would hate to be able to use Koha because it is everything we want except for this issue.
If anyone has seen this before please let me know your thoughts.
This problem has persisted for several months. At some point you might consider professional library data-migration service. You are currently in the strange position of having created new data mapped from your old barcode values, so it is really on you to figure out if they are now correct or not. We can't see your barcodes, your new data or your old data.
--Joe
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel -- Michael Hafen Systems Analyst and Programmer Washington County School District Utah, USA
for Koha checkout http://koha-dev.washk12.org or git://koha-dev.washk12.org/koha _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
On 2009/06/23, at 8:54 AM, Roche III, Edward wrote:
OK...now I opened a item record (through Webmin)like I was going to edit it didn't change anything then saved the record and now I can enter that barcode and it will allow me to check it out with no error. These barcodes were import into a temp table then I ran a UPDATE sql statement to update the barcodes in the item table from the temp table. Can anyone think of a reason why the system will not find the barcode unless I open and save the record first?
well, if you *manually* use sql to UPDATE your barcode values , zebra doesnt know about that ;) so rebuild your zebra-index after, and try searching again FYI: the correct way to do this is to use the C4:Items:ModItems() subroutine - then zebra is updated correctly too
2009/6/22 Mason James <mason.loves.sushi@gmail.com>
On 2009/06/23, at 8:54 AM, Roche III, Edward wrote:
OK...now I opened a item record (through Webmin)like I was going to edit it didn't change anything then saved the record and now I can enter that barcode and it will allow me to check it out with no error. These barcodes were import into a temp table then I ran a UPDATE sql statement to update the barcodes in the item table from the temp table. Can anyone think of a reason why the system will not find the barcode unless I open and save the record first?
well, if you *manually* use sql to UPDATE your barcode values , zebra doesnt know about that ;)
so rebuild your zebra-index after, and try searching again
FYI: the correct way to do this is to use the C4:Items:ModItems() subroutine - then zebra is updated correctly too _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
There's technically a second layer between the Koha MySQL database and Zebra: the MARC holdings tags. Whenever you update something in the biblio, biblioitems, or items table, you have to run misc/batchRebuildBiblioTables.pl to update the MARC record, and then run rebuild_zebra . (Note that, as Mason said, it usually is easier to use the Perl API to do this; it'll update the items table and MARC record, and queue the record to be updated in Zebra.) -- Jesse Weaver
Thanks Jesse and Mason for the help. Now I am a novice when it comes to working with Perl…so, can you tell me a little more about the Perl API? How does It work? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" From: Jesse [mailto:pianohacker@gmail.com] Sent: Monday, June 22, 2009 7:14 PM To: Mason James Cc: Roche III, Edward; koha-devel Subject: Re: [Koha-devel] Barcode Not Found 2009/6/22 Mason James <mason.loves.sushi@gmail.com> On 2009/06/23, at 8:54 AM, Roche III, Edward wrote:
OK...now I opened a item record (through Webmin)like I was going to edit it didn't change anything then saved the record and now I can enter that barcode and it will allow me to check it out with no error. These barcodes were import into a temp table then I ran a UPDATE sql statement to update the barcodes in the item table from the temp table. Can anyone think of a reason why the system will not find the barcode unless I open and save the record first?
well, if you *manually* use sql to UPDATE your barcode values , zebra doesnt know about that ;) so rebuild your zebra-index after, and try searching again FYI: the correct way to do this is to use the C4:Items:ModItems() subroutine - then zebra is updated correctly too _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel There's technically a second layer between the Koha MySQL database and Zebra: the MARC holdings tags. Whenever you update something in the biblio, biblioitems, or items table, you have to run misc/batchRebuildBiblioTables.pl to update the MARC record, and then run rebuild_zebra . (Note that, as Mason said, it usually is easier to use the Perl API to do this; it'll update the items table and MARC record, and queue the record to be updated in Zebra.) -- Jesse Weaver
Running the batchRebuildBiblioTables.pl then the rebuild_zebra.pl didn’t work either. I used the –c switch with the batchrebuld, is that correct? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" From: Jesse [mailto:pianohacker@gmail.com] Sent: Monday, June 22, 2009 7:14 PM To: Mason James Cc: Roche III, Edward; koha-devel Subject: Re: [Koha-devel] Barcode Not Found 2009/6/22 Mason James <mason.loves.sushi@gmail.com> On 2009/06/23, at 8:54 AM, Roche III, Edward wrote:
OK...now I opened a item record (through Webmin)like I was going to edit it didn't change anything then saved the record and now I can enter that barcode and it will allow me to check it out with no error. These barcodes were import into a temp table then I ran a UPDATE sql statement to update the barcodes in the item table from the temp table. Can anyone think of a reason why the system will not find the barcode unless I open and save the record first?
well, if you *manually* use sql to UPDATE your barcode values , zebra doesnt know about that ;) so rebuild your zebra-index after, and try searching again FYI: the correct way to do this is to use the C4:Items:ModItems() subroutine - then zebra is updated correctly too _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel There's technically a second layer between the Koha MySQL database and Zebra: the MARC holdings tags. Whenever you update something in the biblio, biblioitems, or items table, you have to run misc/batchRebuildBiblioTables.pl to update the MARC record, and then run rebuild_zebra . (Note that, as Mason said, it usually is easier to use the Perl API to do this; it'll update the items table and MARC record, and queue the record to be updated in Zebra.) -- Jesse Weaver
How would you use the C4:Items:ModItems() API? Is this a script that needs to be run? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Roche III, Edward Sent: Monday, June 22, 2009 10:53 PM To: koha-devel Subject: Re: [Koha-devel] Barcode Not Found Running the batchRebuildBiblioTables.pl then the rebuild_zebra.pl didn’t work either. I used the –c switch with the batchrebuld, is that correct? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" From: Jesse [mailto:pianohacker@gmail.com] Sent: Monday, June 22, 2009 7:14 PM To: Mason James Cc: Roche III, Edward; koha-devel Subject: Re: [Koha-devel] Barcode Not Found 2009/6/22 Mason James <mason.loves.sushi@gmail.com> On 2009/06/23, at 8:54 AM, Roche III, Edward wrote:
OK...now I opened a item record (through Webmin)like I was going to edit it didn't change anything then saved the record and now I can enter that barcode and it will allow me to check it out with no error. These barcodes were import into a temp table then I ran a UPDATE sql statement to update the barcodes in the item table from the temp table. Can anyone think of a reason why the system will not find the barcode unless I open and save the record first?
well, if you *manually* use sql to UPDATE your barcode values , zebra doesnt know about that ;) so rebuild your zebra-index after, and try searching again FYI: the correct way to do this is to use the C4:Items:ModItems() subroutine - then zebra is updated correctly too _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel There's technically a second layer between the Koha MySQL database and Zebra: the MARC holdings tags. Whenever you update something in the biblio, biblioitems, or items table, you have to run misc/batchRebuildBiblioTables.pl to update the MARC record, and then run rebuild_zebra . (Note that, as Mason said, it usually is easier to use the Perl API to do this; it'll update the items table and MARC record, and queue the record to be updated in Zebra.) -- Jesse Weaver
On 2009/06/24, at 6:21 AM, Roche III, Edward wrote:
Is this a script that needs to be run?
no, its a subroutine in ./C4/Items.pm, see... http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=C4/ Items.pm;h=6c58365ef0d192d4ee7126823397f3f7fc9c9780;hb=HEAD#l453
How would you use the C4:Items:ModItems() API?
take a look here for an example of it being used in a script http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=catalogue/ updateitem.pl;h=7b0b673727fe1e55299332a2ff13a1130ebe2f41;hb=HEAD
Forgot to add the list back on to my response to Mason.... So if I change the lostitem fields to what I need to update and should do it? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Mason James [mailto:mason.loves.sushi@gmail.com] Sent: Tuesday, June 23, 2009 5:45 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found On 2009/06/24, at 6:21 AM, Roche III, Edward wrote:
Is this a script that needs to be run?
no, its a subroutine in ./C4/Items.pm, see... http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=C4/ Items.pm;h=6c58365ef0d192d4ee7126823397f3f7fc9c9780;hb=HEAD#l453
How would you use the C4:Items:ModItems() API?
take a look here for an example of it being used in a script http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=catalogue/ updateitem.pl;h=7b0b673727fe1e55299332a2ff13a1130ebe2f41;hb=HEAD
I updated the fields to include the barcode field in updateitem.pl and saved it as a new file. Now do I run it like I would the other PERL scripts that are used to import a catalog or rebuild zebra because when I do that it shows me HTML code instead of executing the script. Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Roche III, Edward Sent: Wednesday, June 24, 2009 11:50 AM To: koha-devel Subject: Re: [Koha-devel] Barcode Not Found Forgot to add the list back on to my response to Mason.... So if I change the lostitem fields to what I need to update and should do it? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Mason James [mailto:mason.loves.sushi@gmail.com] Sent: Tuesday, June 23, 2009 5:45 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found On 2009/06/24, at 6:21 AM, Roche III, Edward wrote:
Is this a script that needs to be run?
no, its a subroutine in ./C4/Items.pm, see... http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=C4/ Items.pm;h=6c58365ef0d192d4ee7126823397f3f7fc9c9780;hb=HEAD#l453
How would you use the C4:Items:ModItems() API?
take a look here for an example of it being used in a script http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=catalogue/ updateitem.pl;h=7b0b673727fe1e55299332a2ff13a1130ebe2f41;hb=HEAD _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
Has anyone used updateitem.pl script before after importing data into the items table? Whenever I run it displays html instead of any type of progress. Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Roche III, Edward Sent: Wednesday, June 24, 2009 1:03 PM To: Roche III, Edward; koha-devel Subject: RE: [Koha-devel] Barcode Not Found I updated the fields to include the barcode field in updateitem.pl and saved it as a new file. Now do I run it like I would the other PERL scripts that are used to import a catalog or rebuild zebra because when I do that it shows me HTML code instead of executing the script. Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Roche III, Edward Sent: Wednesday, June 24, 2009 11:50 AM To: koha-devel Subject: Re: [Koha-devel] Barcode Not Found Forgot to add the list back on to my response to Mason.... So if I change the lostitem fields to what I need to update and should do it? Thanks! Ed Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437 "At the End of the Day, Did You Play to Win or Not to Lose?" -----Original Message----- From: Mason James [mailto:mason.loves.sushi@gmail.com] Sent: Tuesday, June 23, 2009 5:45 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found On 2009/06/24, at 6:21 AM, Roche III, Edward wrote:
Is this a script that needs to be run?
no, its a subroutine in ./C4/Items.pm, see... http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=C4/ Items.pm;h=6c58365ef0d192d4ee7126823397f3f7fc9c9780;hb=HEAD#l453
How would you use the C4:Items:ModItems() API?
take a look here for an example of it being used in a script http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=catalogue/ updateitem.pl;h=7b0b673727fe1e55299332a2ff13a1130ebe2f41;hb=HEAD _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
You can't run that kind of script from the command line. On Thu, Jun 25, 2009 at 3:43 PM, Roche III, Edward < edward_roche@solanco.k12.pa.us> wrote:
Has anyone used updateitem.pl script before after importing data into the items table? Whenever I run it displays html instead of any type of progress.
Thanks! Ed
Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
-----Original Message----- From: Roche III, Edward Sent: Wednesday, June 24, 2009 1:03 PM To: Roche III, Edward; koha-devel Subject: RE: [Koha-devel] Barcode Not Found
I updated the fields to include the barcode field in updateitem.pl and saved it as a new file. Now do I run it like I would the other PERL scripts that are used to import a catalog or rebuild zebra because when I do that it shows me HTML code instead of executing the script.
Thanks! Ed
Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
-----Original Message----- From: koha-devel-bounces@lists.koha.org [mailto:koha-devel-bounces@lists.koha.org] On Behalf Of Roche III, Edward Sent: Wednesday, June 24, 2009 11:50 AM To: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
Forgot to add the list back on to my response to Mason....
So if I change the lostitem fields to what I need to update and should do it?
Thanks! Ed
Edward J. Roche Network Administrator Solanco School District 717.786.2151 x2437
"At the End of the Day, Did You Play to Win or Not to Lose?"
-----Original Message----- From: Mason James [mailto:mason.loves.sushi@gmail.com] Sent: Tuesday, June 23, 2009 5:45 PM To: Roche III, Edward Cc: koha-devel Subject: Re: [Koha-devel] Barcode Not Found
On 2009/06/24, at 6:21 AM, Roche III, Edward wrote:
Is this a script that needs to be run?
no, its a subroutine in ./C4/Items.pm, see... http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=C4/ Items.pm;h=6c58365ef0d192d4ee7126823397f3f7fc9c9780;hb=HEAD#l453
How would you use the C4:Items:ModItems() API?
take a look here for an example of it being used in a script http://git.koha.org/cgi-bin/gitweb.cgi?p=Koha;a=blob;f=catalogue/ updateitem.pl;h=7b0b673727fe1e55299332a2ff13a1130ebe2f41;hb=HEAD
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha.org http://lists.koha.org/mailman/listinfo/koha-devel
participants (5)
-
Jesse -
Joe Atzberger -
Mason James -
Michael Hafen -
Roche III, Edward