It's much more polite to crosspost so all the newsgroups are included in the
header, rather than multiposting (same question posted separately to
different newsgroups) as you did here.  Your question on this subject about
reports was answered in another newsgroup. For other good suggestions on
effective use of newsgroups, see the FAQ at
http://www.mvps.org/access/netiquette.htm.

There will be some minor differences, because of differences between the
object model of Reports and the object model of Forms, but, the answer is
"yes". Here's the rather lengthy response that I didn't post to the other
question, because I saw it had already been answered (but, a little
experimentation and research on your part may turn up a simpler way to do
this for Forms, beacause there are events on Controls on Forms, and fewer
restrictions.

Yes, but the operative phrase is "description of a field in a table" -- the
following places the description of Field "BoatData" from "tblBoats" in the
Control "txtDescription" when used in the Print event of the Detail Section
a Report.

   Me.txtDescription =
CurrentDb.TableDefs!tblBoats.Fields("BoatData").Properties("Description").Value

It is an interesting exercise, because if you attempt to generalize you
encounter the fact that you have to use text notation, because RecordSource
and ControlSource are text values, not objects.

If the Report is bound to the Table, then RecordSource will contain the name
of the table in string or text form. In that case, you can use:

   Me.txtDescription =
CurrentDb.TableDefs(Me.RecordSource).Fields("BoatData").Properties("Description").Value

And, you could use the Control Source of Control txtBoatData, as well, as in

   Me.txtDescription =
CurrentDb.TableDefs(Me.RecordSource).Fields(Me.txtBoatData.ControlSource).Properties("Description").Value

Finally, you can omit the .Value from the end, as that is the default
Property of the Description Property.

Now, with all that said, the only reason I can see for obtaining the
Description at runtime is to allow for the situation in which the
Description is changed, and you don't want to have to modify the Report.
That could prevent human error, e.g., forgetting to change the Report when
the Description changes, so may repay the extra work of figuring out and
coding the details of obtaining it.

The complexity is due to the fact that RecordSource and ControlSource
Properties are text values, and that not all the Properties of the orignal
Field are carried along and available in the RecordSource of the Report, as
best I am able to determine.  And, because there are no events for Controls
on Reports, only for Sections, and for the Report itself, this can't be
generalized to "any Control on the Report" -- you have to know which TextBox
(or other Control) whose Description you want.

Larry Linson
Microsoft Access MVP