Newbie advice

[Jeff Bandle]

Thanks for all the feedback and great tips.  Unfortunately, there are a lot of lookups that are coded in the same way, so a lot of work to do.  However, this does give me a strategy moving forward.  I will implement the message idea and see how often we hit it.  In looking at it more, this problem seems to stem from an earlier bug where a credit card response is received with with a good status, yet that status is not recognized as an approval and thus approval code information is not saved.  I'm trying to track down the process where that happens.

-----Original Message-----
From: Filepro-list <filepro-list-bounces+jeffbandle=gmail.com at lists.celestial.com> On Behalf Of Richard Kreiss via Filepro-list
Sent: Wednesday, August 25, 2021 9:21 AM
To: mschw at athenet.net
Cc: filepro-list at lists.celestial.com
Subject: Re: Newbie advice

That is why I usually use a qualifier to avoid such a problem. 

I have used qualifiers and associated fields for years. 



Richard
Sent from my iPhone

> On Aug 25, 2021, at 8:59 AM, Mike Schwartz via Filepro-list <filepro-list at lists.celestial.com> wrote:
> 
>      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 writte

_______________________________________________
Filepro-list mailing list
Filepro-list at lists.celestial.com
Subscribe/Unsubscribe/Subscription Changes http://mailman.celestial.com/mailman/listinfo/filepro-list