[373] in ad-lib
More on Barcodes
daemon@ATHENA.MIT.EDU (Eric Celeste )
Wed Apr 19 17:23:55 1995
To: acq2@MIT.EDU
Cc: ad-cat@MIT.EDU
Date: Wed, 19 Apr 95 17:23:36
From: efc@MIT.EDU (Eric Celeste )
Well, the story has evolved since my last message...
The good news is that there are no duplicate barcodes in the database. The
bad news is that the Acq system allowed data from one order to overwrite
data from another order in the pieces database.
This is pretty confusing stuff, so let me walk through one of the examples
Charlene gave me:
1. Order 95-54417, Selling free enterprise, received in Acq system
with barcode 39080009281038.
2. Order 95-54423, Development in the Asia Pacific, received in Acq
system with barcode 39080009281038. Advance issues no warning about
the duplicate barcode number.
3. The "overnight" process moves Acq data to the "main" bib and pieces
databases. Advance automatically...
(a) ... creates a record in the pieces database for 95-54417
with the barcode 39080009281038...
(b) ... creates a record in the bib database for 95-54417
with LCN 10717089 and links this bib record
to piece 39080001038...
(c) ... tries to create a record in the pieces database
for 95-54423 with the barcode 39080009281038, but
when it finds that barcode already in use Advance
overwrites the existing piece record with the new
information instead...
(d) ... creates a record in the bib database for 95-54423
with LCN 10717096 and links this bib record
to piece 39080001038.
4. I search the catalog and find two bib records (10717089 and
10717096) linked to the same item (39080001038). A barcode
search only retrieves 10717096.
It turns out that the Acq system _does_ check for duplicate barcode
numbers, but it only checks the barcode being entered agains barcodes
already existing in the pieces file. Since steps 1 & 2 occured on the same
day, before _either_ barcode moved to the pieces file, no warning was
issued. We tried receiving another order in Acq today using the same
barcode, and the system refused to use the duplicate number.
The problem, of course, is that the common mistake of using the same
barcode twice in a row will _not_ be caught. It does look like Advance
needs a fix here.
For a second example of this problem, look at barcode 39080009281285 which
is attached to both LCN 10717136 and 10717137.
I wonder what would happen if the orders were created one day, transfered
to the main database overnight, then both received the next day with the
same barcode?
Happy debugging!
...Eric
Eric Celeste / MIT Libraries / 14E-210A / 617-253-0633 / efc@mit.edu
