microsoft.public.access.forms

"Douglas J. Steele" wrote in
news:OFNqV#OFIHA.1168@TK2MSFTNGP02.phx.gbl:

> "David W. Fenton" wrote in message
> news:Xns99D1A43828D4Ff99a49ed1d0c49c5bbb2@216.196.97.142...
>> "Douglas J. Steele" wrote in
>> news:O5JcswEFIHA.936@TK2MSFTNGP06.phx.gbl:
>>
>>> Rather than doing the calculation as the control source of the
>>> control on your form, do it as a computed field in a query, and
>>> use that query as the form's RecordSource.
>>
>> If you're not using the value for filtering or sorting, I'd say
>> to *not* put it in the query/recordsource, but put it in the
>> controlsource. The reason is that the calculation won't happen
>> until you load the requested record(s), rather than as soon as
>> Rushmore finishes populating the recordset. This is particularly
>> relevant for reports, where there is no need whatsoever for
>> calculated fields anywhere except in controls *unless* your
>> report logic somehow depends on using that value for something
>> other than display.
>
> I don't disagree with that, David.
>
> However, it sounded as though Calvin wanted the data available
> elsewhere (or why else would he be concerned that the calculation
> wasn't being saved?) By using a query, he'd have a compromise.

I agree that if you're using the QueryDef in multiple locations and
need the calculated value in multiple locations then, yes, it makes
sense to put it in the QueryDef.

But as a general principle, I would put calculations in the last
level, i.e., the form or report controls.

--
David W. Fenton http://www.dfenton.com/
usenet at dfenton dot com http://www.dfenton.com/DFA/