Newbie advice

Richard Kreiss rkreiss at verizon.net
Wed Aug 25 07:20:44 PDT 2021


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



More information about the Filepro-list mailing list