Situation -

Formula's that contain the @RECORD refernce in them i.e.

x=@RECORD * @RECORD

can be easily converted by using the dictionary references,

x=ICONV{OCONV{QTY},'MD0') * OCONV({UNIT_PRICE},'MD2'),'MD2')

but where @RECORD is assigned as the result of a calculation such as..

E=ICONV(OCONV{QTY},'MD0') * OCONV({UNIT_PRICE},'MD2'),'MD2')

@RECORD=E

@ANS=E

is there a way to assign the a dictionary name as the value of the calculation since @RECORD is "unreliable" in an OI form?

I have to ask .. why do you save calculated data?

dsig@sigafoos.org

DSigs Radio Free Oregon

Leon:

Does the assignment happen in a form?

If so, the simplest thing is to put hidden controls on the form, update them there.

Another option are to have the write event update those fields. On the read event, cache a copy of the record in a UDP. On the write event, Merge the data from the form with the cached record, write that.

You could also have an MFS that updates those fields whenever the record is written. A cheesy way to do that is to make a calculated field which does all the updating, @ans=@id, put a btree on that, have SI.MFS be your post-save mfs.

Finally, I am starting to play with table_based commuter modules to complement window_based commuter modules. That way I can have symbolics, OI windows, JOI windows, web forms and MFS's all execute the same business rules.

Bob

Bob,

Regarding your comment about table-based commuter modules. I am working on a product called ATLAS, which has as this as a fundamental feature.

First, an MFS program POST_MFS provides the logic framework for transaction processing. POST_MFS calls routines which perform the actual posting or updating based on control information entered for each table. The posting routines typically contain a post routine for writing, a post routine for deleting or reversing, and nothing else. The data-entered control specifies the conditions for updating, which are evaluated by POST_MFS.

POST_MFS also writes a temporary record of the information being posted, which is deleted if the posting is successful. If the posting fails, the user may roll the transaction forward (retry the posting), roll it back (reverse the transaction), or delete the tracking record.

I may not have explained this well. If you have questions or I can be of help, let me know.

Gerald

glovel@wares.cc

800-727-4587

Several Reasons -

1. Customers change names due to mergers, conversions to LLP, etc -

 Record customer name at the time an Invoice is created and store 

 in record - Legal liability 

2. Store Actual Tax % and tax amounts at time Invoice or Order is

 generated due to tax rate changes - parishes, county, state, 

 metro, etc., - some orders span over 1 year in shipments, and

 and taxes may change during that time, so we show taxes at the

 time of acceptance...

The best time to do this is at the time of generation, just in case the user changes the tax rate code, etc.

I agree wholeheartedly. It's very useful to store Symbolic data in real fields.

And in payroll systems, it's pretty much manditory since the Symbolic information is usually calculated from a table (but the table is only good for one year). When this is necessary a lot, I use a Symbolic to calculate the data in the "Null Default", and then put it into actual fields to save. That way it doesn't get recalculated again if the screen is brought up. Also, my accounting software always protects the data once a record has been posted through the system to the G/L. The only way to correct it is to enter a reversing transaction.

Don M.

Good answers ..

For the company we force the creation of a new compay record (easy Clone over). Then no info on the lookup id changes.

The taxes .. yeah I think this is the only place where we have 'knowingly' stored this type of data.

thanks for the reply

dsig@sigafoos.org

DSigs Radio Free Oregon

View this thread on the forum...