You need an age field. Seems annoying from a programmers point of view, but that's how filemaker works.
And the age field should be an unstored calculation field, not a stored calculation nor a data field with an auto-entered calculation.
So I need a Text obj with an AGE field added to the d/b table; that field not being 'Stored'. Yeah, that is an annoyance from programming.
Would it make any sense to add another table to the d/b for useless_junk, then put the AGE field and other fields that never need storage and get recalc'd dynamically? Just a thought.
Thanks for teh help guys
Moving the field off to a separate table might make life complicated for you later. I'd suggest you leave the field in your main table, but perhaps name it (and other fields you class as useless_junk) in such a way that you can see what it is and skip over it. I've prefixed some fields with a leading "_" so they are grouped together. I've seen similar recommendations for grouping globals with a "g_" prefix.
Good point there.
As things grow it might be a bit complicated; especially as others might be involved in future dev. I think I'll stick with junk_age, junk_[etc..].
There are ways you can do this with a variable used as merge text that avoids using a field. I'm not totally convinced that the added work justifies that approach for every possible calculation field, but it can be done if you are using FileMaker 11.
LaRetta is a strong proponent of that approach. If you search this forum for the phrase "I declare variables", you'll probably find several by her on this approach.
The basic idea is to add the variable to your layout as merge text: <<$Age>> and use a conditional format expression that uses the Let function to assign the computed value to this same variable.