Error Handler

[Steve Dentler]

I know it's a bear to follow someone elses script when it's more than several lines long, but, I using A5's Commit/Rollback in the below listed script to post an invoice register to vendor files and to the General ledger. The outer while loop posts to vendors (Vendbal.dbf) and the inner while loop is posting the GL (GLbal.dbf). I've removed additional code which moves records to appropriate history files and sets milestones, etc. for readability. I'm using Commit/Rollback to insure integrity amoung the tables.

In testing the routine, I locked a vendor record using the A5V5 beta, switched back to A5V4 (build 243), and ran the post. All was well, and either all records posted or none. In the second test, I locked a GL account in the same fashion and again ran the posting routine.

The error handler triggered and warned that the table was in use (I suspect this warning is being generated by the fetch method being employed on a table in change mode). On releasing the msg box by pressing the "OK" button, I get a second expected message that a portion of the file is in use (namely the record I knowingly have locked). I then switch to A5V5 beta and release the record, switch back to A5V4 and again press the "OK" button to complete the posting operation. At this point the script executes to completion.

But on checking the tables, I find that the lock record never posts.

Because of the sequence of error messages, and the failed posting, it seems that the "Resume 0" statement is returning the script to the line immediately *AFTER* the offending line instead of the offending line.
Any help...thoughts...suggestions, appreciated.

option nobreak
a = table.open("apinvset.set")
b = table.get("apinvdtl")
c = table.open("vendbal")
d = table.open("ApTrans")
e = table.open("Glbal")
f = table.open("sy02")

c.index_primary_put("Vendprd")
e.index_primary_put("Acctprd")
f.index_primary_put("PDDate")

a.fetch_first()
while .not. a.fetch_eof()
f.fetch_find(a.postprd)
vndkey = a.vendid + a.postprd
if exist(vndkey,"Vendbal","Vendprd") then
c.fetch_find(vndkey)
c.change_begin()
commit_flag = .t.
on error goto ERROR
c.amount = c.amount + a.invamt
else
c.enter_begin()
commit_flag = .t.
on error goto ERROR
c.fiscalyr = substr(a.postprd,3,4)
c.vendno = a.vendid
c.postprd = a.postprd
c.begprd = f.beg_date
c.endprd = f.end_date
c.amount = a.invamt
end if

b.fetch_first()
while .not. b.fetch_eof()
vglkey = remspecial(b.glno) + a.postprd
if exist(vglkey,"Glbal","Acctprd") then
e.fetch_find(vglkey)
e.change_begin()
e.amount = e.amount + b.amt
e.change_end(commit_flag)
else
e.enter_begin()
e.fiscalyr = substr(a.postprd,3,4)
e.acctno = remspecial(b.glno)
e.postprd = a.postprd
e.begprd = f.beg_date
e.endprd = f.end_date
e.amount = b.amt
e.enter_end(commit_flag)
end if
b.fetch_next()
end while

if c.mode_get() = 2 then
c.enter_end(commit_flag)
elseif c.mode_get() = 1 then
c.change_end(commit_flag)
end if

a.fetch_next()
end while

a.close()
c.close()
d.close()
e.close()
f.close()
end

ERROR:
commit_flag = .f.
err = error_code_get()
msg = error_text_get(err)
ui_msg_box("Error",msg)
resume 0

Thanks,
-Balto Cpa

[Peter.Wayne]

RE: Error Handler

As you say, it's hard to follow someone else's code, so
I may have this wrong, but your error handler is setting c
commit_flag to .f., so you enter_end(commit_flag) will fail.
There is no rollback in A5 - only a cancellation of the
commit.

[Steve Dentler]

RE: Error Handler

Thanks Peter,
You're right about the rollback, the cancellation is the closest we have in A5 to a rollback. However, I discovered (through no particular brillance) that the placement of the ON Error Goto statement is the key to having this work. I simply loaded up the script with numerous On Error Goto's and started deleting them after the script was working correctly. The revised script works as advertised. I know the script is hard to follow, but just note the placement of the On Error Goto's to have the script function correctly. This placement seems to have the Resume 0 command return correctly, albeit, I know not why!

option nobreak
a = table.open("apinvset.set")
b = table.get("apinvdtl")
c = table.open("vendbal")
d = table.open("ApTrans")
e = table.open("Glbal")
f = table.open("sy02")

c.index_primary_put("Vendprd")
e.index_primary_put("Acctprd")
f.index_primary_put("PDDate")

a.fetch_first()
while .not. a.fetch_eof()
f.fetch_find(a.postprd)
vndkey = a.vendid + a.postprd
if exist(vndkey,"Vendbal","Vendprd") then
c.fetch_find(vndkey)
c.change_begin()
commit_flag = .t.
ON ERROR GOTO Error
c.amount = c.amount + a.invamt
else
c.enter_begin()
commit_flag = .t.
ON ERROR GOTO Error
c.fiscalyr = substr(a.postprd,3,4)
c.vendno = a.vendid
c.postprd = a.postprd
c.begprd = f.beg_date
c.endprd = f.end_date
c.amount = a.invamt
end if

b.fetch_first()
while .not. b.fetch_eof()
vglkey = remspecial(b.glno) + a.postprd
if exist(vglkey,"Glbal","Acctprd") then
e.fetch_find(vglkey)
e.change_begin()
commit_flag =.t.
ON ERROR GOTO Error
if b.amt

[Peter.Wayne]

RE: Error Handler

You shouldn't need all your ON ERROR GOTO ERROR statements. A single ON EROROR GOTO [i]label should remain in effect until it is turned off
with an ON ERROR GOTO 0 statement.
There is also a command - I forget it at present - that will
give you the line number of the error. That would be useful
to you in figuring out what triggers the ON ERROR GOTO and then you
can use the debugger to see if, in fact, the RESUME 0 statement
is returning you to the wrong place. I have generally found thta the ON ERROR GOTO and RESUME statements work just fine.

Usually I do this, though, in error trapping:

on error goto err_trap
t=table.open("mytable",file_rw_exclusive)
on error goto 0
t.fetch_first()
..etc.
t.close()
end

err_trap:
on error goto 0
ui_msg_box("File in use","Try later")
end

That is, I turn off the error trap as soon as I pass
the line in which I want it to work. That way I avoid an
endless loop if another error pops up. It also helps me to
pinpoint each error.

[Steve Dentler]

RE: Error Handler

Thanks, Peter,
I'll experiment with it a little and try your suggestion on turning off the error trap.