Browse lookup
GCC Consulting
gcc at optonline.net
Thu Dec 16 07:15:53 PST 2004
There is an interesting error which can arise with browse lookups and it may be
difficult to trap.
Situation:
On first execution of the browse, one record is displayed (under other
circumstances there could be more then one record). Processing is done against
this record by pressing <S>-select @bk="S".
The browse format uses drop on a specified lookup field to delete specific
records from the display. When the process against this record is completed,
this field is set to the value not to be displayed. The program them loops back
to display records again.
Since there are no matching records, the first error I received was 'No Records
For This Browse". As John Esak explained in the Chat Room, using -s option
would eliminate this message.
However, the routine drops through and also shows lookup field no found on the
line that reads
if: @bk = "S" and foobar(40) = ""
then: in=foobar(1);ia=foobar(6) .........
This problem came up as I was testing a new cash application routine I have been
working on. Under normal usage, this error should not occur. The procedure
gets the check amount and then lists the open invoices. Pressing <S> selects the
invoice to process and requests the amount to apply. If the check amount is
less then the balance due on the invoice, pressing <enter> would apply the
balance of the check. Once a payment has been applied to the invoice, a field is
set causing that invoice top be dropped from the display. On the amount applied
equals the amount of the check, the program end out.
However, if an amount less then the full check is entered, everything processed
normally and the program redisplays the browse expecting there to be more
invoices.
Since I do a check for open invoices when the account code is entered, I added a
routine to count the number of open items. If there is only one item, I put up
an error message that the amount being applied in less then the check amount.
The only thing I need to do now is check with the client and see if they get
cash on account to be applied. If they do, I'll have to work out this
procedure.
I think we need a way to more gracefully trap browse lookup errors. Yes, we can
do a lookup first to make sure that is at least one record matching the lookup
criteria and if not display our own message or run some other routine. However,
in my can I received the standard browse error and then the drop routine
executed, I think, causing the second error.
Richard Kreiss
GCC Consulting
More information about the Filepro-list
mailing list