[Koha] automatic barcode numbers

Fri May 29 18:55:51 NZST 2009

Hi Joe,

Thanks for the reply.

I understand the idea of machine identifier but, as you can probably  
tell from my choice of the given options for auto-barcodes, I tend to  
prefer things that mean something. This is especially true for number  
based codes. BranchYYMMNNNN is an option (or at least was in 3.0.0  
stable), so I took it. If it isn't - then why is it there?

I agree that getting Koha to go through the entire catalogue and look  
for the max value is dumb. When Koha got stuck for a couple of weeks  
and forgot how to increment, I  wrote down the last barcode number  
that was added and then incremented that each time. Surely something  
like that would be much less intensive, than having to go rummaging  
through the whole database each time.

ie. for incrmented numbers (which mine is), you don't need to ask  
"what's the current MAX value?" You just need to ask (and have Koha  
remember) "what was the last value, for the branch I'm dealing with?"  
I don't code well, but I'd imagine that this would take maybe a row or  
two attached to each branch you were looking after.

-ramon
(assuming that people like sequential numbers, and that the rest of  
you don't mind non-codeing folk making suggestions)

On 28/05/2009, at 8:58 AM, Joe Atzberger wrote:

> Ramon --
>
> Correct, it is not possible to mix and match barcode types and  
> expect everything to work.  This problem cannot be "fixed", because  
> the proposed use is the broken part.  To understand what I mean,  
> think of the logical dimensions of the problem.  The autopopulation  
> question is "what is the next value?"   So we have to ask "what is  
> the current MAX value?".  But what if the MAX value is not a valid  
> barcode according to the current format?  Then Koha can't answer  
> correctly.
>
> Each barcode format has a defined namespace of valid values, so you  
> might think "we'll only look for the max of currently valid  
> values".  But those namespaces collide.  For example, a system (like  
> Plano ISD) can use numerical branch codes.  So branchYYMMNNN might  
> look like 1050905001.  That would also be a valid incremental  
> barcode.  And anyway, running a regexp on say 200,000 items (or  
> more) just to figure out what the next barcode value should be is a  
> fundamentally dumb way to design a system, performance-wise.
>
> That's why the bottom line, for me anyway, is not to use anything  
> but incremental.  Then when we ask for MAX(barcode) we just get the  
> top value from the mysql index of that column's values.
>
> In short, the intent of a barcode is to be a machine identifier.   
> The barcode label when printed can now include arbitrary text for  
> human consumption including the branch code, branch name, date  
> acquired, etc. so there is no longer any reason to put that stuff  
> into the barcode itself.
>
> -- 
> Joe Atzberger
> LibLime - Open Source Library Solutions
>
>
> On Wed, May 27, 2009 at 7:05 PM, Ramon Andinach <custard at westnet.com.au 
> > wrote:
> Hi Oliver,
>
> I confess I've never thought to try just saving the item and expecting
> the barcode to show up.
> I'm finding that it appears when you shift focus (click in or tab
> through the barcode box) while entering the item details.
>
> But,
>
> That doesn't really answer the question does it?
> I also remember it not quite playing ball and getting stuck at a
> particular number, but it's been a little while since I did enough
> cataloging to have it happen, so I've forgotten the precise details. I
> do remember it getting quite irate at the supposed unique number it
> had just picked not being unique.
>
> I haven't upgraded to the new stable version yet, and maybe it's fixed
> there. In previous threads on this topic it's been revealed that there
> are problems, particularly with the nifty looking branchYYMMNNN form
> and that fixing this code is fairly low priority. The fixes offered
> have been 1) just don't use it, 2) sponsor one of the developers to
> fix it, 3) buy some premade barcodes and scan them in at the time of
> cataloguing.
>
> I've been using the branchYYMMNNN one (which is apparently the worst
> of the lot), and because I only get to do a little bit at once, I'm
> able to remember what the last obok was (and hence the last barcode)
> and fix the subsequent ones. Which is annoying but not that time
> consuming. I also found that it became unconfused when the month
> changed (for a while).
>
> Mayphaps this helps a bit.
> (although probably not)
>
> ramon/custard
>
>
>
> On 26/05/2009, at 9:41 PM, Oliver Bernuetz wrote:
>
> > We're having the same problem and our autoBarcode is set to ON.
> > I've created items and saved them and no barcode appears.
> >
> > Oliver D. Bernuetz, BA Adv, MLIS
> > Information Specialist/Librarian | Specialiste de l'information/
> > Bibliothècaire
> >
> >  
> _____________________________________________________________________________________________________________
> > From: koha-bounces at lists.katipo.co.nz [mailto:koha-bounces at lists.katipo.co.nz
> > ] On Behalf Of Rachel Hamilton-Williams
> > Sent: May 25, 2009 5:03 PM
> > To: Carmel Young; koha
> > Subject: Re: [Koha] automatic barcode numbers
> >
> > Hi Carmel,
> >
> > Check that it isn't really doing it - it's a bit confusing.
> >
> > You expect the number to come up when you add in the item details,
> > but it doesn't do it until after you've submitted the  form the
> > first time.
> >
> > Cheers
> > Rachel
> >
> > Carmel Young wrote:
> > Using Koha 3.00 on Lenny.
> >
> > Problem:   When adding records, the barcode does not automatically
> > present the next sequential number.  Can anyone help?
> >
> > Carmel Young
> > Catholic University of Malawi.
> >
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>