Barcodes have ZEROS?!?!!?!?



  • Ok so my friend works at a supermarket chain and is currently the only maintainer of their entire chain's database... Well granted that they pay him 10 bucks an hr (poor fella i keep telling him he can get a better job)

    So here is a great story about the BRILLIANCE of the designer of the system:

    "The designer decided that UPC codes (the bar codes on every product) are to be stored as NUMBERS. So a product with 0000170 will be identical primary key as product with 000170 bar code (possible and would be very feasible considering that bar codes are allowed to have leading zeros and SHOULD have leading zeros if the number is too small). So thats a major problem. Every time 2 products collide I have to delete manually from the database the old product that is hopefully not used anymore. And granted that everyone using this system is borderline retarded they just punch the numbers in and then come crying to me when the store comes to a screeching crash. I yell at them but it does not help.

    The store decided to upgrade their systems and against my pleas of sanity they hired consultants (you guys should figure the rest of the story at this point) who decided that the best way to upgrade the system to ensure that bar codes don't collide is to store them as NUMBERS. I guess faster searching is more important than the product actually working."


    But this tale is one of great saddness...

    "You see my graduation project was supposed to be this system upgrade. However the consultants completely locked me out of it, and the project was in such terrible shape that it was abandoned. And thus my graduation project was not completed (the bastards!)"

    Anyone hiring an intern?  :)



  • I'm a little confused here.  The original problem happened because the UPC column used NUMBERS, but the consultants solution was to change this to NUMBERS (i.e. no change it at all)?



  • @Outlaw Programmer said:

    I'm a little confused here.  The original problem happened because the UPC column used NUMBERS, but the consultants solution was to change this to NUMBERS (i.e. no change it at all)?

    That's what I got out of it, yes... that they did not fix the problem.

    The obvious solution is to store the number as a string ("00000172"), but the consultants are correct in that the numbers-as-strings would take a teensy tiny bit longer to process (string maniuplation versus arithmetic).  But I guess extracting every last .000001% of system performance is better than, you know, the system actually performing as intended.  They obviously graduated from the school of "it's wrong, but at least it's fast!"



  • Hang on, he's saying that they have barcodes for different products which differ only in the number of leading zeroes?

    In what fucked-up universe are UPCs assigned like that? That is not how they work on this planet. Every product has a UPC that is precisely 12 digits long - no more and no less - and hence its integer representation is unique.

    Even the 13-digit EAN system is fully compatible and has no conflicts.
     


  • Discourse touched me in a no-no place

    @WhiskeyJack said:

    @Outlaw Programmer said:

    I'm a little confused here.  The original problem happened because the UPC column used NUMBERS, but the consultants solution was to change this to NUMBERS (i.e. no change it at all)?

    That's what I got out of it, yes... that they did not fix the problem.

    The obvious solution is to store the number as a string ("00000172"), but the consultants are correct in that the numbers-as-strings would take a teensy tiny bit longer to process (string maniuplation versus arithmetic).  But I guess extracting every last .000001% of system performance is better than, you know, the system actually performing as intended.  They obviously graduated from the school of "it's wrong, but at least it's fast!"

    From the OP I sense that the primary key of 'bar code' isn't, as it should be, unique:

    The designer decided that UPC codes (the bar codes on every product) are to be stored as NUMBERS. So a product with 0000170 will be identical primary key as product with 000170 bar code [...] So thats a major problem. Every time 2 products collide I have to delete manually from the database the old product that is hopefully not used anymore.

    Assuming all bar codes have exactly the same number of numbers in them, I fail to see how changing the format of the primary key is going to help.

    If this is in the US, (UPC uses 12 digits,) and the numbers in the OP are 'real ones' it would appear that they're not actually using the whole bar code.



  • @Outlaw Programmer said:

    I'm a little confused here.  The original problem happened because the UPC column used NUMBERS, but the consultants solution was to change this to NUMBERS (i.e. no change it at all)?

    Correct! 



  • @WhiskeyJack said:

    @Outlaw Programmer said:

    I'm a little confused here.  The original problem happened because the UPC column used NUMBERS, but the consultants solution was to change this to NUMBERS (i.e. no change it at all)?

    That's what I got out of it, yes... that they did not fix the problem.

    The obvious solution is to store the number as a string ("00000172"), but the consultants are correct in that the numbers-as-strings would take a teensy tiny bit longer to process (string maniuplation versus arithmetic).  But I guess extracting every last .000001% of system performance is better than, you know, the system actually performing as intended.  They obviously graduated from the school of "it's wrong, but at least it's fast!"

    Trust me, a half-retarded half-man half-bear half-pig programmer who graduated from dumpster university could have figured that out, except of course for the consultants and the original architect. 



  • @PJH said:

    @WhiskeyJack said:

    @Outlaw Programmer said:

    I'm a little confused here.  The original problem happened because the UPC column used NUMBERS, but the consultants solution was to change this to NUMBERS (i.e. no change it at all)?

    That's what I got out of it, yes... that they did not fix the problem.

    The obvious solution is to store the number as a string ("00000172"), but the consultants are correct in that the numbers-as-strings would take a teensy tiny bit longer to process (string maniuplation versus arithmetic).  But I guess extracting every last .000001% of system performance is better than, you know, the system actually performing as intended.  They obviously graduated from the school of "it's wrong, but at least it's fast!"

    From the OP I sense that the primary key of 'bar code' isn't, as it should be, unique:

    The designer decided that UPC codes (the bar codes on every product) are to be stored as NUMBERS. So a product with 0000170 will be identical primary key as product with 000170 bar code [...] So thats a major problem. Every time 2 products collide I have to delete manually from the database the old product that is hopefully not used anymore.

    Assuming all bar codes have exactly the same number of numbers in them, I fail to see how changing the format of the primary key is going to help.

    If this is in the US, (UPC uses 12 digits,) and the numbers in the OP are 'real ones' it would appear that they're not actually using the whole bar code.

     

    To be honest I had the same though but given the fact that:

    1) The bar codes repeat (apparently it is true)

    and

    2) The users are alowed to enter invalid data causing the program to come to a screeching halt

    I am ASSUMING that something went wrong with the coding. 



  • @dlikhten said:

    Trust me, a half-retarded half-man half-bear half-pig programmer who graduated from dumpster university could have figured that out, except of course for the consultants and the original architect. 

    A programmer with 4 halves is twice the programmer I am... I should be ashamed.

    Fortunately I'm not.



  • @WhiskeyJack said:

    The obvious solution is to store the number as a string ("00000172"), but the consultants are correct in that the numbers-as-strings would take a teensy tiny bit longer to process (string maniuplation versus arithmetic).  But I guess extracting every last .000001% of system performance is better than, you know, the system actually performing as intended.

    Um, wow. Ignoring the fact that UPC codes don't actually work like that, using strings would be a lot slower (not 0.00001% like you suggest) and would take up more storage space. If the length of the UPC code was actually the issue, I'd just add a 1-byte length property and add an additional check to the existing code.

     

    Why are you so set on using strings? It would require a large rewrite, it would be a lot slower, it would take up more space, and wouldn't even fix the actual problem since UPC codes don't work that way. You're being incredibly nasty to these people, yet their solution is elegant and fast and yours is worse in every way.



  • Changing the datatype from INT to STRING should really not take a huge rewrite, unless you're an idiot and made too many premature optimizations that depend on the datatype.

     

    Speed? Worry about correctness first.  ALWAYS worry about if your program is correct.  It's easier to make things faster. It's harder to make things work. 

    Most data access layers (even ADO.NET) would be able to handle this change in a few hours.

    I think the problem is that the store isn't using UPC barcodes for all of its products. UPC codes are not supposed to collide.

    I'm not sure I'd store a UPC as INT.  When I do barcode lookups for our Point-Of-Sale add-on to our application, I do them as (n)varchar to be flexible (barcodes can store lots of characters, e.g., Code128). The speed isn't a problem as the bottlenecks are elsewhere (the user).

     



  • @imikedaman said:

    their solution is elegant and fast and doesn't resolve the issue.  Therefore anything you create is inferior.

    Thought so. 

    He never mentioned that he was working with UPC codes, just barcodes.  Take note. 



  • @belgariontheking said:

    He never mentioned that he was working with UPC codes, just barcodes.  Take note.

    No, he really does say UPC - check the first post. Plus all supermarkets use UPC anyway.



  • @belgariontheking said:

    @imikedaman said:

    their solution is elegant and fast and doesn't resolve the issue.  Therefore anything you create is inferior.

    Thought so. 

    He never mentioned that he was working with UPC codes, just barcodes.  Take note. 

    @dlikhten said:

    The designer decided that UPC codes (the bar codes on every product)

    I think he did...



  • @MasterPlanSoftware said:

    @belgariontheking said:

    Thought so. 

    He never mentioned that he was working with UPC codes, just barcodes.  Take note. 

    @dlikhten said:

    The designer decided that UPC codes (the bar codes on every product)

    I think he did...

    Who went back and changed his original post and all quotes of it so it would look like I was wrong?  :) 



  • @Benanov said:

    I think the problem is that the store isn't using UPC barcodes for all of its products. UPC codes are not supposed to collide.

    See, that's the strange part. UPC was created for supermarkets, and every product on supermarket shelves are supposed to have UPC. Whatever the problem is with their system, switching to strings certainly wouldn't fix the actual issue. Maybe it doesn't have any validation measures or doesn't remove outdated UPCs correctly? Or maybe the database itself is bad?



  • @imikedaman said:

    Um, wow. Ignoring the fact that UPC codes don't actually work like that, using strings would be a *lot* slower (not 0.00001% like you suggest) and would take up more storage space. If the length of the UPC code was actually the issue, I'd just add a 1-byte length property and add an additional check to the existing code.

    Why are you so set on using strings? It would require a large rewrite, it would be a lot slower, it would take up more space, and wouldn't even fix the actual problem since UPC codes don't work that way. You're being incredibly nasty to these people, yet their solution is elegant and fast and yours is worse in every way.

    OK, I'll grant that UPC codes may not work that way, I admit I didn't look it up as I was going by my interpretation of the problem as written by the OP, which was that there were independent items with the same cardinal value, but differing numbers of leading zeroes, like "0000172" and "000172".

    Yes, strings would be slower and take more space.  I'm assuming that in the 21st century world of terabyte hard drives and multi-gigahertz CPUs, this isn't such an issue anymore.  So it takes 12 ms instead of 13.  I can live with that, if that's what it takes to solve the problem.

    Now, like you say, if that's not how it's supposed to work, then obviously converting to strings won't help so this would be a moot point anyway.

     

     



  • The next person to say "UPC code" is going to get an ATM machine machine thrown at their head.



  • @asuffield said:

    The next person to say "UPC code" is going to get an ATM machine machine thrown at their head.

    UPC code.

    You asked for it.


  • Discourse touched me in a no-no place

    @asuffield said:

    The next person to say "UPC code" is going to get an ATM machine machine thrown at their head.
    RAS syndrome?



  • @MasterPlanSoftware said:

    @asuffield said:

    The next person to say "UPC code" is going to get an ATM machine machine thrown at their head.

    UPC code.

    You asked for it.

    This should take care of most of the argument.



  • @Benanov said:

    Changing the datatype from INT to STRING should really not take a huge rewrite, unless you're an idiot and made too many premature optimizations that depend on the datatype.

     

    Speed? Worry about correctness first.  ALWAYS worry about if your program is correct.  It's easier to make things faster. It's harder to make things work. 

    Most data access layers (even ADO.NET) would be able to handle this change in a few hours.

    I think the problem is that the store isn't using UPC barcodes for all of its products. UPC codes are not supposed to collide.

    I'm not sure I'd store a UPC as INT.  When I do barcode lookups for our Point-Of-Sale add-on to our application, I do them as (n)varchar to be flexible (barcodes can store lots of characters, e.g., Code128). The speed isn't a problem as the bottlenecks are elsewhere (the user).

     

    There is a quote: "The root of all programming evil is premature optimization". 



  • @asuffield said:

    The next person to say "UPC code" is going to get an ATM machine machine thrown at their head.

    UPC Code.  I love redundancy.  I love redundancy.

    UPC Code.  I love redundancy.  I love redundancy. 

    I'll take that ATM machine now.  Is it pre-filled with money?

    I'll take that ATM machine now.  Is it pre-filled with money?

    I can't seem to remember my PIN number.

    I can't seem to remember my PIN number.

    Have you heard about Microsoft's NT Technology?

    Have you heard about Microsoft's NT Technology?

    I went to the library and looked something up using the ISBN Number.

    I went to the library and looked something up using the ISBN Number.

    Do you have the HIV Virus?

    Do you have the HIV Virus?

    My new television has an LCD Display.

    My new television has an LCD Display.

    I've got a credit card that charges 20.9% APR.

    I've got a credit card that charges 20.9% APR.
     


  • Discourse touched me in a no-no place

    @MasterPlanSoftware said:

    @MasterPlanSoftware said:

    @asuffield said:

    The next person to say "UPC code" is going to get an ATM machine machine thrown at their head.

    UPC code.

    You asked for it.

    This should take care of most of the argument.

    I'm failing to see how it's relevant to what you're quoting.



  • @belgariontheking said:

    @asuffield said:

    The next person to say "UPC code" is going to get an ATM machine machine thrown at their head.

    UPC Code.  I love redundancy.  I love redundancy.

    UPC Code.  I love redundancy.  I love redundancy. 

    I'll take that ATM machine now.  Is it pre-filled with money?

    I'll take that ATM machine now.  Is it pre-filled with money?

    I can't seem to remember my PIN number.

    I can't seem to remember my PIN number.

    Have you heard about Microsoft's NT Technology?

    Have you heard about Microsoft's NT Technology?

    I went to the library and looked something up using the ISBN Number.

    I went to the library and looked something up using the ISBN Number.

    Do you have the HIV Virus?

    Do you have the HIV Virus?

    My new television has an LCD Display.

    My new television has an LCD Display.

    I've got a credit card that charges 20.9% APR.

    I've got a credit card that charges 20.9% APR.
     

    What the WTF?  ;)
     



  • @WhiskeyJack said:

    @imikedaman said:

    Um, wow. Ignoring the fact that UPC codes don't actually work like that, using strings would be a *lot* slower (not 0.00001% like you suggest) and would take up more storage space. If the length of the UPC code was actually the issue, I'd just add a 1-byte length property and add an additional check to the existing code.

    Why are you so set on using strings? It would require a large rewrite, it would be a lot slower, it would take up more space, and wouldn't even fix the actual problem since UPC codes don't work that way. You're being incredibly nasty to these people, yet their solution is elegant and fast and yours is worse in every way.

    OK, I'll grant that UPC codes may not work that way, I admit I didn't look it up as I was going by my interpretation of the problem as written by the OP, which was that there were independent items with the same cardinal value, but differing numbers of leading zeroes, like "0000172" and "000172".

    Yes, strings would be slower and take more space.  I'm assuming that in the 21st century world of terabyte hard drives and multi-gigahertz CPUs, this isn't such an issue anymore.  So it takes 12 ms instead of 13.  I can live with that, if that's what it takes to solve the problem.

    Now, like you say, if that's not how it's supposed to work, then obviously converting to strings won't help so this would be a moot point anyway.

     

    Last time I checked, we make fun of companies that run in to problems and just throw more hardware at it.  I think perhaps the company doesn't want to spend the money to buy all new hardware because some programmer is two stupid to realize that storing a 12 digit number as a string is a lot slower and takes up a lot more disk space (and bandwidth to a server) than storing it as numbers.  Furthermore, it doesn't matter 2 shits if they are stored as strings or as numbers since the problem apparently is that two products have the exact same bar code. 



  • @dlikhten said:

    There is a quote: "The root of all programming evil is premature optimization".

    You two are confusing premature optimization with a solid initial design. Premature optimization is trying to cache every reused value, reusing variables of similar types if they're used in disjoint places, and implementing various domain-specific tricks before your code works correctly. Good initial design is choosing the proper data structures and the general flow of the algorithms before you start coding at all.



  • @tster said:

    Last time I checked, we make fun of companies that run in to problems and just throw more hardware at it.  I think perhaps the company doesn't want to spend the money to buy all new hardware because some programmer is two stupid to realize that storing a 12 digit number as a string is a lot slower and takes up a lot more disk space (and bandwidth to a server) than storing it as numbers.  Furthermore, it doesn't matter 2 shits if they are stored as strings or as numbers since the problem apparently is that two products have the exact same bar code.

    I think what they're saying is that while it technically would be many orders of magnitude slower comparing 12-character strings than a single number comparison, it will still be plenty fast for normal usage. They may very well be right about it too, although there's of course no way of actually proving or disproving it without knowing the type of hardware being used. And the person you quoted already acknowledged that it's a moot point even arguing this since it doesn't fix the core problem.


    Also, "two stupid"? Come on, man! Talk about ironic. ;)



  • @tster said:

    @WhiskeyJack said:

    @imikedaman said:

    Um, wow. Ignoring the fact that UPC codes don't actually work like that, using strings would be a *lot* slower (not 0.00001% like you suggest) and would take up more storage space. If the length of the UPC code was actually the issue, I'd just add a 1-byte length property and add an additional check to the existing code.

    Why are you so set on using strings? It would require a large rewrite, it would be a lot slower, it would take up more space, and wouldn't even fix the actual problem since UPC codes don't work that way. You're being incredibly nasty to these people, yet their solution is elegant and fast and yours is worse in every way.

    OK, I'll grant that UPC codes may not work that way, I admit I didn't look it up as I was going by my interpretation of the problem as written by the OP, which was that there were independent items with the same cardinal value, but differing numbers of leading zeroes, like "0000172" and "000172".

    Yes, strings would be slower and take more space.  I'm assuming that in the 21st century world of terabyte hard drives and multi-gigahertz CPUs, this isn't such an issue anymore.  So it takes 12 ms instead of 13.  I can live with that, if that's what it takes to solve the problem.

    Now, like you say, if that's not how it's supposed to work, then obviously converting to strings won't help so this would be a moot point anyway.

     

    Last time I checked, we make fun of companies that run in to problems and just throw more hardware at it.  I think perhaps the company doesn't want to spend the money to buy all new hardware because some programmer is two stupid to realize that storing a 12 digit number as a string is a lot slower and takes up a lot more disk space (and bandwidth to a server) than storing it as numbers.  Furthermore, it doesn't matter 2 shits if they are stored as strings or as numbers since the problem apparently is that two products have the exact same bar code. 

    Except that EAN is coming soon and UPC-A is just EAN with a 0 (zero) for the country code.  If the store wanted to issue its own UPC-like codes, the UPC specification has a nice big section specifically devoted to coupon codes which are designed just for this reason.

    Not only to mention that barcode data, in this usage of it, should be treated like a magic cookie.  Don't modify it, don't think about its data type and how to optimize it, just use it. 

    And, put in me the "let's be real" camp when we talk about making things faster with numbers.  Clearly, that didn't work, did it?

    UPC-A numbers are 12-digits long.  They can start with any digit.  So, they require 10 hex digits.  Or 5 bytes.  Are people really insisting here that saving seven or eight bytes per record is a huge savings?  A store might have a million SKUs.  We're talking 8 megabytes.  That's in the "so f-ing what" category.



  • Nearly forgot.  Since many stores now sell books, they must deal with ISBN numbers.  An ISBN number may legitimately contain an "X".  Note: "ISBN number" is just the terminology used by those who deal with them.  Yes, it is technically not a number-number, but, that's what they use.

    So, again, storing the SKUs are integers ... just bad juju.



  • @James Shields said:

    An ISBN number may legitimately contain an "X".

    Yes. But that's only because the "X" signifies a special number. it is "actually" still a number, just with the additional typographic convention that "if this piece here is ten, then print an X instead of a numeral"; you can read it as a number just fine (10).

    (And I'd like to thank Wikipedia for letting me brush up on this...)



  • @James Shields said:

    Nearly forgot.  Since many stores now sell books, they must deal with ISBN numbers.  An ISBN number may legitimately contain an "X".  Note: "ISBN number" is just the terminology used by those who deal with them.  Yes, it is technically not a number-number, but, that's what they use.

    No they don't. Convert the ISBN-10 into a ISBN-13 which is the same as the EAN-13 (Add 978 to the beginning of the first 9 digits, and recalculate the check digit)



  • @tster said:

    Last time I checked, we make fun of companies that run in to problems and just throw more hardware at it.  I think perhaps the company doesn't want to spend the money to buy all new hardware because some programmer is two stupid to realize that storing a 12 digit number as a string is a lot slower and takes up a lot more disk space (and bandwidth to a server) than storing it as numbers.  Furthermore, it doesn't matter 2 shits if they are stored as strings or as numbers since the problem apparently is that two products have the exact same bar code. 



    What calculations are you expecting to do with the barcode?  It's probably just the index, so it really doesn't matter whether it's a string or number, unless you're running the database off a zip disk or something.  I'm pretty sure if the [b]bandwidth[/b] of your database server is causing problems, you're either running a massive scientific simulation or something has gone horribly wrong.



  • My company does product identification using barcodes all the time. The most simple (and sometimes hard to obey) rule is of course: barcodes content should be unique. If that's not possible, introduce other criteria that allow you to identify the item uniquely.

    So apart from the fact that to my knowledge product numbers for supermarkets should be fixed length and unique (like EAN 9 or EAN 13), what would be the big deal just additionally storing the date and time the product was added to the database and extending the primary key to UPC and date? That way you could just select the newest product from the database that matches your UPC. Boom, PK constraint violation gone.

    Using the above solution you would not have to delete items anymore. However, it would not solve the problem that the older product may still be in use.



  • @Zemm said:

    @James Shields said:

    Nearly forgot.  Since many stores now sell books, they must deal with ISBN numbers.  An ISBN number may legitimately contain an "X".  Note: "ISBN number" is just the terminology used by those who deal with them.  Yes, it is technically not a number-number, but, that's what they use.

    No they don't. Convert the ISBN-10 into a ISBN-13 which is the same as the EAN-13 (Add 978 to the beginning of the first 9 digits, and recalculate the check digit)

    I'd like to see 1) Developers on systems written in the 70s-90s to have predicted ISBN-13

    2) You to convert the barcode on every BOOK in a large bookstore or library from ISBN-10 into ISBN-13 (this can be avoided if every time a barcode is scanned the system converts ISBN-10 into ISBN-13, but I think that's going to nullify any speed increases from changing the database)

    Also, don't forget that ISBNs sometimes get released with invalid check digits, when the publisher makes an error and doesn't catch it. So you can't assume that a checksum error automatically means an invalid ISBN (-10 or -13) has been entered.

    PS: Anyone seen any SCUBA apparatus?



  • To those so stuck on numbers (which is a great indication that you haven't dealt with serious barcoding before), I want to know this:

    1. Just how crappy is your database "server" if another 10MB of data is such a huge deal?

    2. And how unbelievably crappy is your database "server" if serving up indexed short strings (14 bytes) takes orders of magnitude longer than serving up indexed numbers (6 bytes each, that's right, 12 and 13 digit numbers don't fit nicely in a 4-byte simple integer)?

    Contrary to many of the simplistic notions here, UPC and EAN barcodes are intended to be taken as a whole.  The zeros in front are significant and meaningful.  Just scan them and use them.  Why get clever?  Why tempt fate?  Unless your database server totally sucks, you're not going to get any real performance gains.  You're not going to save any real space.  Why not just leave things neat and tidy and use it verbatim?  You know, magic cookie ... like a GUID or the primary key in a relational database.

    Had the original developers just taken the barcodes verbatim and used them as is, none of this would be an issue.  But, they got clever.  And, that's where it all broke down.  And, that's what some here are advocating.  "Oh, I know better."  Wrong.

    They could've also done research and discovered UPC coupon codes.  But, I suspect, that might've been just too hard.  Imagine, using the right tool for the job.



  • @Outlaw Programmer said:

    I'm a little confused here.  The original problem happened because the UPC column used NUMBERS, but the consultants solution was to change this to NUMBERS (i.e. no change it at all)?

    Yeah!!!  Totally boneheaded, eh?

     http://en.wikipedia.org/wiki/Universal_Product_Code

     I gather the part left out here is that the kid working for $10/hour was going to put together the system in a less boneheaded way.

     I'm amazed this chain got consultants that couldn't do the least bit of research on UPC bar codes.
     



  •  @m0ffx said:

    1) Developers on systems written in the 70s-90s to have predicted ISBN-13

    2) You to convert the barcode on every BOOK in a large bookstore or library from ISBN-10 into ISBN-13

    My comment was on having to read "X" (As a potential check digit in an ISBN) as part of a barcode. Every book I have access to right at the moment (which admittedly is only a few: most of my books are at my weekend house) has an ISBN (either 10 or 13, depending on the age) and a barcode which is the ISBN-13.

    For example "Ring" by Koji Suzuki (English version) has "ISBN 0-00-717885-9" and barcode 9780007178858, which is also its ISBN-13.  A newer book, "Please Explain" by Dr Karl Kruszelnicki has "ISBN 978-0-7322-8535-7" with the barcode the same.

    So (2) has already happened hasn't it?

    @m0ffx said:

    Also, don't forget that ISBNs sometimes get released with invalid check digits, when the publisher makes an error and doesn't catch it. So you can't assume that a checksum error automatically means an invalid ISBN (-10 or -13) has been entered.

    Well if they release an invalid ISBN-13 no barcode scanner will read it. If they have an invalid ISBN-10 then the check digit will be recalculated when the barcode is made.


Log in to reply