Filepro-list Digest, Vol 36, Issue 17

GCC Consulting gccconsulting at comcast.net
Tue Jan 16 10:21:04 PST 2007


 

> -----Original Message-----
> From: 
> filepro-list-bounces+gccconsulting=comcast.net at lists.celestial
> .com 
> [mailto:filepro-list-bounces+gccconsulting=comcast.net at lists.c
> elestial.com] On Behalf Of Tom Carey
> Sent: Tuesday, January 16, 2007 2:37 AM
> To: filepro-list at lists.celestial.com
> Subject: Re: Filepro-list Digest, Vol 36, Issue 17
> 
> Thank you for the replies to my question.
> 
> I have another question. On the same system there is an order 
> entry record. 
> That record has associated fields that repeat 32 times. Each 
> instance of the associated field represents a complete item 
> order. The relevant portion of the file layout is below.
> 
> Item number               S0)    fld # 21    10,*
> Qty ordered               S1)    fld # 22     4,.0
> Qty Shipped               S2)    fld # 23     4,.0
> Qty Back ordered      S3)    fld #  24      4,.0
> Description                 S4)   fld # 25     31,*
> Unit price                   S5)    fld # 26     7,.2
> flag                             S6)    fld # 27    2,allup
> extended price.           S7)    fld # 28     8,.2
> Dept number               S8)   fld # 29      7,*
> 
> The fields repeat 31 more times.
> 
> In the update mode. The data entry person can change any 
> field but the extended price. They can even add new lines to 
> the order.
> 
> Here is the problem. When the order is initially entered the 
> Qty ordered is added to the product file to tell  mfg how 
> many of each item to make. When the order is shipped, the 
> record is placed in the update mode and the Qty shipped is 
> added. All seems well at this point. When the order is 
> completed the Qty ordered is subtracted from the product 
> file. Any BO is reentered into the system as a new order. All is well.
> 
> The problem occurs when the order is modified at update time. 
> The Qty on order may be changed. The item number may be 
> changed. The price may be changed. Entire new line items may 
> be added to the order.
> 
> My intent is to store the associated fields in an array at 
> the entry into update mode. At the end of the update, go thru 
> the array and compare the initial values to the final values 
> so I can detect changes to Qty ordered. 
> item number, new lines etc. At that point I know what action 
> has to be taken to make sure that the product file is 
> correctly handled.
> 
> At this point I don't know of an easy way to get the 
> associated fields into the array upon entry into the update 
> mode. I am using the system field @AF during add mode to 
> index the array and populate it as the data is initially 
> entered.  Unfortunately, the system objects if I try to 
> manipulate  @AF.  I have looked at overlaying an array but 
> don't see how I can make that work. I looked at overlaying an 
> array as a column but the fields of the same type are not 
> sequentially numbered.
> i.e. item number is fld 21,30,39 etc.
> 
> Any ideas on how I can stuff the data into an array before 
> the operator gets a shot at it would be greatly appreciated.
> 
> To make things worse , only the first 30 occurrences of the 
> associated fields are contiguous in the record layout, the 
> last two occurrences were tacked on to the end of the record.
> 
> Before anyone throws rocks for the way file is laid out, I 
> didn't do it. I inherited this system and am cleaning up the 
> mess, learning Filepro as I go.
> 
> I can't begin to tell you folks what it means to have someone 
> to ask questions of and get guidance from. I don't feel that 
> I am all alone without any resources other than the on-line 
> manuals. Thank you for being there.
> 
> Tom Carey

If you plan to use arrays, yes arrays, you will need to dim an array for
each associated field group for the initial values and a second set to
capture any changes. i.e. items(32) and dim items_chg(32):21 (hold the
changed values). This will be a total of 16 arrays. 

Read in the initial values when first entering the record or when entering
each field.  

At the end of the process, compare the 2 matching array elements to see if
any value changed.  If something changed, apply the proper processing.    

Start::ct="1"
loop:item(ct)ne item_chg(ct):GOTO doit
::oqty(ct) ne oqty_chg(ct):GOTO doit
::sqty(ct) ne sqty_chg(ct):GOTO doit
Compare balance of the arrays
:ct lt "32":ct=ct+"1",GOTO loop 
::GOTO end_it

Doit::'do your posting here
:ct = "32":GOTO end_it
::ct=ct+"1";GOTO loop

Granted you will be posting both changed and unchanged values for a line
item with a change, but it will be simpler logic to handle since only 8
fields are involved.

Richard Kreiss
GCC Consulting
 



    




More information about the Filepro-list mailing list