Re: patron load reports

["Phil Huang" <phil dot huang at sonoma dot edu>]

Sandra's interpretation is excellent.

One more item I would like to add is "m2btab file - m2btab.p".  This
indicates the load table file that the particular loading process uses.  In
this case, the load table file is "m2btab.p".  Most libraries, I guess, just
have one load table for patron load.  So you do not need to specify the
table file.  The system uses "m2btab.p" by default.  However, libraries are
free to have multiple load table files dealing with different types of
patrons that they want to load. For instance, you may have one load table
file for loading records of regular students, one for faculty/staff, another
one for short students, ...  Using multiple load table files allows greater
controls and flexibility.  And it's less error-prone than you otherwise have
to do.  The downside?  You need to write the load table files which requires
special training by III.

Phil Huang
Sonoma State Univ.
Rohnert Park, CA 94928



----- Original Message ----- 
From: "Card, Sandra" <scard at exchange dot calstatela dot edu>
To: "'Kate Wegmann'" <wegmann at email dot unc dot edu>; "'INNOPAC LISTSERV'"
<innopac at innopacusers dot org>
Sent: Wednesday, June 22, 2005 11:03 AM
Subject: RE: patron load reports


> I have been loading patron records since 1996.  What do you need?
>
> On our reports, we see this:
>
>
> Input file  - barcode9.pat              Start date - June 14 11:06AM
> Error file  - barcode9.errlog           End date   - June 14 11:07AM
> m2btab file - m2btab.p
> Number of input records - 5385
> Number of errors        - 0
>                    NEW                         EXISTING     INPUT
TOTAL
>                RECORDS      REC #S ASSIGNED     RECORDS   RECORDS
RECORDS
>                CREATED      START       STOP  OVERLAYED  REJECTED
READ
> PATRON            4509  p1185425x  p11899335        876         0
5385
>
> This means that of the 5385 records in this particular file, 876 matched
on,
> and updated 876 existing records.  4509 new records were created, and the
> beginning and ending numbers of the new records are shown in the start /
> stop columns.
>
> This file had no errors.  But from another load, a line on an error report
> looks like this.  I supplied the column headings (the system does not):
>
> BLOCK#    MATCH point       Problem                      Name of patron in
> incoming record
> 68009  Overlay code = e:u, 2 matches, record inserted / Castellon, Ramon
> Eduardo
>
> We match on a campus id number.  This line means that our patron file had
> two records with the same id number.  Since the system cannot decide which
> record to update, it creates a third record and reports the situation.
>
> 64925    Overlay failed for p11729065, Record p11729065 in use by system,
> new record inserted / Asgari, Marjan
>
> This means someone is using the record that the system would normally
> update.  It then creates a second record and reports it.
>
> In the first type of error, I find it is fastest to go into the load file
> and look at block 68009 in the load file (e.g. barcode9.pat).  I then copy
> the id number into a search on the patron file and merge the duplicate
> patron records as needed.  If you do not have access to the load file, do
a
> patron search under name, get the id number (or whatever your system
matches
> on) and redo the search using the id number.  This is because names may
> occur in variations and are not a reliable way to find duplicates.
>
> In the second case, a busy record, I usually wait a bit and check the
record
> no. that was busy.  If it is no longer busy, I do a search to pull up the
> old and new records and then merge them.
>
>
> Also, I find it very useful to do a test load first (the TEST button on
the
> load screen).  I can then get an error report and fix any reported
> duplications in the database before I load the records for real. This
means
> I only have to merge two records instead of three.
>
> Sandra Card
> Library
> California State University, Los Angeles
> scard at calstatela dot edu
> 323-343-4894
>
>
> -----Original Message-----
> From: Kate Wegmann [mailto:wegmann at email dot unc dot edu]
> Sent: Wednesday, June 22, 2005 10:32 AM
> To: innopac at innopacusers dot org
> Subject: patron load reports
>
>
> Hi,
>
> I work for the Circulation Department at the University of North
> Carolina at Chapel Hill, and we went live with Millennium about a month
> ago.  We recently ran our first set of tape loads of updated patron
> information and received the summary reports generated by Millennium.
>  Unfortunately, no one knows how to read the summary reports.  We've
> contacted III and have been told that there is no formal document on how
> to interpret patron load reports.
>
> So...has anyone else encountered this problem?  Does anyone know how to
> read the reports?
>
> Any information or suggestions would be very very much appreciated!
>
> Thanks,
> Kate
> -- 
> Kate Wegmann
> Borrower's Card Assistant
> Davis Library
> University of North Carolina-Chapel Hill
>
>
> --- StripMime Report -- processed MIME parts --- multipart/alternative
>   text/plain (text body -- kept)
>   text/html
> ---
> --
> This message was distributed through the Innovative Users Group INNOPAC
list
> Public replies:  INNOPAC at innopacusers dot org Update your subscription
options:
> http://innopacusers.org/mailman/listinfo/innopac
>
>
> --- StripMime Report -- processed MIME parts ---
> multipart/alternative
>   text/plain (text body -- kept)
>   text/html
> ---
>
>