I have a field that isn't recalculating:

Field type; Date

Auto Enter Calculation: Get (CurrentDate)

Storage: None (Auto create....)

Commit record and Refresh Window, flush doesn't cause recalculation either.

The field is a date field as opposed to a calc field because I am doing reporting using the date.

It's an Auto-Enter calculation. That means the data is entered on record creation or when a stored field in the calculation is modified.

Commit[] and Refresh[] won't update such a calc.

What exactly are you trying to accomplish by having the current date stored in a field? It's unlikely you actually need to do that.

DJ, your right. I wanted to preserve the field as a date field, for date to be used in date calculations. I see now that I could make it a calculation field that stores it as a date anyway, and this field is working dynamically.

Thanks

It either stores it OR works dynamically (unstored).

In fact, an unstored calculation of current date is redundant, because you can always get the value directly from the Get (CurrentDate) function. You only need such field if you want to use it as a matchfield in a relationship showing today's records.

You can make auto-enter calc fields work *almost* like stored calculations by doing this:

left ( currentTable::modifiedTimeStamp , 0 ) & get(currentdate)

Make sure "Do not replace existing value of field" is **NOT** ticked.

Auto-enter calcs are re-evaluated whenever there is a change to any of the fields that the reference. Since currentTable::modifiedTimeStamp will automatically change whenever anything else in the record changes, the AEC will be re-evaluated too.

The left(whatever,0) bit will of course return absolutely nothing, but it's a nice quick way of including 'whatever' in the calc.

Hope that helps.

James

And if the record is not modified first thing every morning?

I did say *almost* :-)

I usually use that solution in conjunction with a scheduled server script that ensures all the records in all tables of a file are modified. A simple 'replace' of a field with itself does the trick.

However in the situation of the original poster (ie a reporting requirement) I would definitely consider just using an unstored calc... depending on what it is, it probably won't take *that* much longer to run the report and given the choice I would prefer a more accurate report that takes a few moments longer to run.

The AEC method with left(modified,0) is at its most useful when you need an otherwise unindexed calculation on the right-hand side of a relationship.

Cheers

James

a scheduled server script that ensures all the records in all tables of a file are modified.

You could modify a stored CurrentDate field directly, instead of going around by modifying *some* field to get the auto-enter to recalculate.

In any case, I don't think this is good practice, as it renders the LastModified fields useless and runs the risk of encountering locked records. It shouldn't be needed anyway - in most cases it's possible to move the unstored element to the parent side of relationship.