cash-10 service fails to process all records it should when UPDATE = Y is specified

Last updated
Save as PDF
Share
1. Share
2. Tweet
3. Share

Article Type: General
Product: Aleph
Product Version: 18.01

Description:
pc_cash_10 ("Payments Received Report") was run for February 2007 fines. When Update Database was NO, there were 66 records selected. When Update Database was YES there were 43 records. :

Update database NO: start BIN50,cash10febban_20080616,cash10febban_20080616,NAME,20070201,20070228,,,20,N,

The report included 66 fine records.

Update datasbase YES: start BIN50,cash10febbanch_20080616,cash10febbanch_20080616,NAME,20070201,20070228,,,20,Y,

The report included 43 fine records. Fines for the following borrowers were not on the update YES report and when I checked the GUI they had not changed to Transferred to AR: BIN000033632, BIN000055145, BIN000055869, BIN000048702, BIN000046132, BIN000046862, BIN000048881, BIN000037911, BIN000040147, BIN000046699.

Resolution:
p_cash_10 reads the z31 records by date.

Diagnostics show that the bin50_p_cash_10.00574 (with UPDATE = N) processed all of the Feb. 2007 records, while the bin50_p_cash_10.00575 (with UPDATE = Y) processed only through Feb. 19, 2007.

The last three records in the bin50_p_cash_10.00575 run are these:

Z31-REC-KEY= BIN000054669 20070219 1046923
Z31-REC-KEY= BIN000054669 20070219 1046923
Z31-REC-KEY= BIN000054669 20080318 0827818

All of these three records are for patron BIN000054669. The question is why it is jumping ahead and reading this z31 from 20080318. (When it does this, it compares it to the "p_date_to" value of "20070228", finds that it is higher, and stops.)

It's for the same patron as the Feb. 19, 2007, record it had just read -- that's no doubt relevant --, but it should getting the next record by date, not by patron number....

The z31 Oracle date index is z31_id4. I find that it is present and valid in this alephtest-18(1) BIN50. (Of course, if it weren't, it wouldn't be reading the records by date which it is and we would be having much worse problems.)

It may be that if you run the job for smaller intervals -- say, a week at a time -- that you will not see this problem.

Also, **When you are running it on a production basis -- where the "p_date_to" will be a more recent date -- you may not see this problem.** (This may be why this problem has not been reported previously by other sites.)

Article last edited: 10/8/2013