Newbie advice

[mschw at athenet.net]

     I apologize if I wasn't clear about this, Richard, but I meant field 6 in the "his" (dfinvhis) database:  [   816 ::his(6)=inv(16)   ]        

     It is a long shot that the "his" (gfinvhis) database doesn't have a field 6, but I would at least take a minute to check the gfinvhis map.

      I mention this possibility because I've seen programmers make a copy of a database, like an "invoice" database and then use it as an "archive" database, like this "his" (history) database appears to be.  Months or years later they add fields to the invoice database and forget to add those same fields to the end of the "history" database.  Then they write code that *ASSUMES* those additional fields are in the "history" database and can't figure out why the code fails.  

     I suggest this because the first few writes to the "his" database work and then the "his" lookup suddenly fails with a lookup error reminded me of a similar situation several years ago.   

     Often this occurs when a programmer uses an editor like UltraEdit to edit filePro processing tables and then makes too many assumptions that a field is in a database and then doesn't bother to run the code through the filePro syntax check.  

     Since George was a pretty savvy filePro programmer, he might have done this.

----- ----- -----  SIDE NOTE:

    Ok, I'm guilty of this.  (Not always syntax checking when I write code using UltraEdit...)  Skipping syntax check, especially when making a minor change, is unforgivable, but editing text using UltrEdit is so quick and easy when compared to using filePro's "define processing".  Of course I USUALLY catch this in testing...  <grin>

     I use UltraEdit because I can write something like a spreadsheet exporting processing table about 10 times faster in UltraEdit than I can by using "define processing" in filePro.  Also, if I rotate my color monitor to "portrait" mode, I can see as many as three (3) filePro processing tables of 243 lines of filePro code at a time.

       Using an external text editor is really a necessity because, for example, I'm currently working on a project that has filePro processing tables over 5,000 lines long with subroutines it that are a few hundred lines long.   (Yes, I know, this whole project was written in the 1980's and badly needs an overhaul to break these large processing tables into smaller chunks of code...) 

    Also, I like the ability to colorize the text.  In UltraEdit I can make all the gosub's red, all the goto's blue, etc.    
----- ----- -----

Mike Schwartz

-----Original Message-----
From: Richard Kreiss <rkreiss at verizon.net> 
Sent: Wednesday, August 25, 2021 6:34 AM
To: mschw at athenet.net
Cc: filepro-list at lists.celestial.com
Subject: Re: Newbie advice

I think that Mike was referring to field 16 not 6. He is correct in checking for a not after the lookup to see if it was successful. You could also declare a long variable and see if it contains a value after a successful lookup. If the field is empty skip line 816 as nothing will post. You could also put up a message that the field has no value. I would add the not line just after the lookup to inv as this check should be in place for any lookup. 

Also check the map for a field 16. 

Richard Kreiss
GCC CONSULTING
Sent from my iPhone

> On Aug 24, 2021, at 4:34 PM, Mike Schwartz via Filepro-list <filepro-list at lists.celestial.com> wrote:
> 
>      Ok, the lookup for a free record in the "his=gfinvhis" file should
> never fail unless there are extraordinary circumstances, and the "his" 
> file is being written to in lines 811 thru 815 without ant errors.  So 
> it is most likely that there isn't a field #6 in the gfinvhis 
> database.  If there is a field 6 in the gfinvhs database, then 
> possibly the "lookup inv=" file record has not been successfully looked up.
> 
>     Is there a field #6 in the gfinvhis file?    
> 
>     Can you look back in the code and find a "lookup inv=???" line?  
> What filePro database does "lookup inv=" point to?
> 
>      Just before line 816, can you insert a NEW line 816 that says:
> 
> IF:  not inv
> THEN:  msgbox "No INV record found in line 816"
> 
>     Then run the code again and let us know if the "No INV record 
> found in line 816" error message pops up?
> 
> Thanks!
> 
> Mike Schwartz
> 
> -----Original Message-----
> From: Jeff Bandle <jeffbandle at gmail.com>
> Sent: Tuesday, August 24, 2021 2:24 PM
> To: mschw at athenet.net
> Cc: Filepro-list at lists.celestial.com
> Subject: RE: Newbie advice
> 
> Ok.  The following is the code that I think is the culprit as it is 
> handling the reversal of an invoice and that is where it blew up.  It 
> is in a piece of code called REVERSIT.PRC that is called from 
> GFSALES/KEYR.prc code. That code handles the user entering R while looking at an invoice to
> reverse/refund the amount.     The code with line numbers is as follows:
> 
> 809 INVHIST:'inventory history for items that are not sets::
> 810 ::lookup his = gfinvhis  r=free  -e:
> 811 :                                'item code:his(1)=xx: