field modification date

[dysong3]

I'm trying to find a way of having a field automatically record another field's modification date. I have found several threads on this with the following solutions. The only problem is, is that these only work if the field gets changed continually to a differnet value. In my field, the data can only be one of two values. In the solutions indicated below, this works only when it gets changed to the value that wasn't there when the field was defined.

Let (

trigger = dpo calc

;

Get ( CurrentTimeStamp )

)

or

Case(

dpo calc;

Get(CurrentDate);

Get(CurrentDate)

Would someone have an idea for getting around this problem

[comment]

Your question is not clear. The calculations above evaluate when the trigger field is MODIFIED. They don't care what WAS in the field, or what CAN be in it - the only thing that matters is that it changed.

[dysong3]

That's what I would have thought too. However if I have say, value "1" in the field "dpo calc" when I define it, it will effectively show the modification date when I change the value to "2". But when it is changed back to "1" the modification date disappears. As my field "dpo calc" can only have one of two values, I need to have a calculation that gives the date, irrespective of what the value is.

[comment]

I am afraid I still don't follow. When you define a field, it has no value. It acquires a value only when it's filled - by user, or a script or auto-entry - for the purposes of the calculation in question, it doesn't matter how.

when it is changed back to "1" the modification date disappears.

That shouldn't be happening. Make sure the field is of type Timestamp (if using the first formula above), and that it's defined to auto-enter the calculation, replacing existing value. If it still doesn't work, post a file showing the problem.

[fabriceN]

the field name makes me wonder : is dpo calc a calculation ?

[comment]

Would it make a difference?

[fabriceN]

if it relies on related values, yes. It is apparently not the case, but since there seem to be a missing piece of information...

[dysong3]

Fabrice,

Thanks very much for your intervention. I think I have resolved the problem. It seems to be due to the fact that the referenced field is a calculation field. I have since tried referencing a text field instead at it seems to function was you would expect. I still don't understand why it doesn't work correctly with a calc field. But that's not matter, it now works as I want it to.

Thanks once again.

[fabriceN]

You're welcome, that was lucky fishing!

[comment]

It does work with calculation fields, but... if the calculation field references related/global fields (therefore unstored), it will NOT trigger the modification when a related value has been modified. If the modified value is a global, it will trigger ONLY if the global value is in the same table, and only for the current record. This is the correct and expected behavior.

[dysong3]

It doesn't work either if you forget that you need to choose a storage option for the calc field as I had done. Thanks for throwing light onto that.

[comment]

I don't think it really matters here. The calculation field is acting merely as a mediator here - what matters is which fields are being referenced, either directly or indirectly. Say you have a calculation field cCalc =

Valuefield + Related::Value + gValue

and your modification stamp is auto-entering =

Let ( trigger = cCalc ; Get ( CurrentTimeStamp ) )

This will be triggered exactly the same as a field auto-entering =

Let (

trigger = Valuefield & Related::Value & gValue

;

Get ( CurrentTimeStamp )

)

with one exception: if you modify the local matchfield to point at another related record, the 'direct' field will be triggered, but the field referencing the calc will not react.