AnsweredAssumed Answered

Calculated Value vs Calculation Field

Question asked by ShawnAmann on Jul 30, 2010
Latest reply on Jul 30, 2010 by ShawnAmann

Title

Calculated Value vs Calculation Field

Post

I am having some conceptual issues with the above. I have found that the calculated value never seems to do what I want it to do (although it seems like it should) while the unstored calculation always hits the spot. 

What I am doing is having a list table that will store purchase orders and Request for payements. These are two seperate tables. They are feeding into the list table through a realtionship that can create records (I am setting the field in the list table to get the record created)

Now I would like the date created to be my next field in the list. I set that as a date field, calculated value and uncheck the do not replace existing value. The calculation is

Case(
not IsEmpty(PURCHASE_ORDERS::date_created);
PURCHASE_ORDERS::date_created;
not IsEmpty(REQUEST_PAYMENT::Date Created);
REQUEST_PAYMENT::Date Created
)

This does not work as a calculated value. Works fine as an unstored calculation field. 

So I dont get why that is. The PURCHASE_ORDERS::date_created is auto entered and thus exists prior to this calculation being evaluated. (prior to the record it is in even exists) Therefore when the record is created and this calculation runs there should be a value where it expects it. Do calculated values not work across relationships?

So why do I care is the calculation field would work? It seems that unstored calculations would use more system resources as they are always looking to update (not sure if true or if it even matters with a small database) and I want the data to remain unchanged even if the original record is altered. 

Any thoughts. Thanks in advance. This forum has helped tremendously.

Outcomes