Error when trying to use calc field from Query

[Guest]

Whatever I do, I cannot pull a calculated field from a query into a form or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a calculated field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text boxes
and set the sources as Table1.Field1 and Field2, created a further text box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was that you
could create a calculated field and then use it wherever you wanted???
Many thanks
CW

 

[Rob Parker]

It sounds like your form is not bound to a recordsource, and you are trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the names
you have entered. Although it's possible to work with unbound forms, it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and set the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name into
the box on the property sheet, or via the dropdown. Note that you do not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the form
bound to the table, with textboxes bound to Field1 and Field2, and in an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for that
textbox. Another common trap, particularly if you set up your form via a
wizard or drag-and-drop fields, is to have a textbox with the same name as a
field in the form's recordsource; if you enter an expression referring to a
field with the same name as a textbox, you will also get a #Name error. For
this reason, it's good practice to use a naming convention for all your
controls to avoid them having the same name as an underlying field (eg. name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob

 

[Guest]

Rob - thanks a lot for your detailed response.
That certainly explains why my simple test did not work, as you are right I
had not bound the form itself to anything.
However, I was seeing the error originally in my app where the form was
bound to a table and I had taken two of the fields from that table into a
query, then added a calculated field and created an extra text box on the
form and bound that to the calculated field of the query. Given that all the
data I was working with was coming from one and the same table, and given
that the form was bound to that, why would I have got the error there?
Thanks again for your help
CW

It sounds like your form is not bound to a recordsource, and you are trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the names
you have entered. Although it's possible to work with unbound forms, it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and set the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name into
the box on the property sheet, or via the dropdown. Note that you do not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the form
bound to the table, with textboxes bound to Field1 and Field2, and in an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for that
textbox. Another common trap, particularly if you set up your form via a
wizard or drag-and-drop fields, is to have a textbox with the same name as a
field in the form's recordsource; if you enter an expression referring to a
field with the same name as a textbox, you will also get a #Name error. For
this reason, it's good practice to use a naming convention for all your
controls to avoid them having the same name as an underlying field (eg. name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob

Whatever I do, I cannot pull a calculated field from a query into a form
or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a calculated
field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text boxes
and set the sources as Table1.Field1 and Field2, created a further text
box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was that you
could create a calculated field and then use it wherever you wanted???
Many thanks
CW

 

[Douglas J. Steele]

Your form needs to be bound to the query, not the table.

The fact that the query is working with data from the same table is
irrelevant.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

Rob - thanks a lot for your detailed response.
That certainly explains why my simple test did not work, as you are right
I
had not bound the form itself to anything.
However, I was seeing the error originally in my app where the form was
bound to a table and I had taken two of the fields from that table into a
query, then added a calculated field and created an extra text box on the
form and bound that to the calculated field of the query. Given that all
the
data I was working with was coming from one and the same table, and given
that the form was bound to that, why would I have got the error there?
Thanks again for your help
CW

It sounds like your form is not bound to a recordsource, and you are
trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the
names
you have entered. Although it's possible to work with unbound forms,
it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and set
the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name
into
the box on the property sheet, or via the dropdown. Note that you do not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the form
bound to the table, with textboxes bound to Field1 and Field2, and in an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for
that
textbox. Another common trap, particularly if you set up your form via a
wizard or drag-and-drop fields, is to have a textbox with the same name
as a
field in the form's recordsource; if you enter an expression referring to
a
field with the same name as a textbox, you will also get a #Name error.
For
this reason, it's good practice to use a naming convention for all your
controls to avoid them having the same name as an underlying field (eg.
name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob

Whatever I do, I cannot pull a calculated field from a query into a
form
or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and
Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a calculated
field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text
boxes
and set the sources as Table1.Field1 and Field2, created a further
text
box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was that
you
could create a calculated field and then use it wherever you wanted???
Many thanks
CW

 

[Guest]

Ah - thanks Douglas that's a fairly fundamental point!
So if I have a bunch of forms that are currently bound to tables (as I do)
then I would need to write a query for each one that would include all the
necessary fields and change the recordsource for each form from the existing
table to the new query, before I can hope to bring in any calculated fields
that I may construct within those queries?
And presumably I would have to change the control source on every control on
those forms, too?? Blimey, might as well start all over again!!
Would appreciate your confirmation re the action I need to take, thanks.
CW

Your form needs to be bound to the query, not the table.

The fact that the query is working with data from the same table is
irrelevant.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

Rob - thanks a lot for your detailed response.
That certainly explains why my simple test did not work, as you are right
I
had not bound the form itself to anything.
However, I was seeing the error originally in my app where the form was
bound to a table and I had taken two of the fields from that table into a
query, then added a calculated field and created an extra text box on the
form and bound that to the calculated field of the query. Given that all
the
data I was working with was coming from one and the same table, and given
that the form was bound to that, why would I have got the error there?
Thanks again for your help
CW

It sounds like your form is not bound to a recordsource, and you are
trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the
names
you have entered. Although it's possible to work with unbound forms,
it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and set
the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name
into
the box on the property sheet, or via the dropdown. Note that you do not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the form
bound to the table, with textboxes bound to Field1 and Field2, and in an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for
that
textbox. Another common trap, particularly if you set up your form via a
wizard or drag-and-drop fields, is to have a textbox with the same name
as a
field in the form's recordsource; if you enter an expression referring to
a
field with the same name as a textbox, you will also get a #Name error.
For
this reason, it's good practice to use a naming convention for all your
controls to avoid them having the same name as an underlying field (eg.
name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob


Whatever I do, I cannot pull a calculated field from a query into a
form
or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and
Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a calculated
field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text
boxes
and set the sources as Table1.Field1 and Field2, created a further
text
box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was that
you
could create a calculated field and then use it wherever you wanted???
Many thanks
CW

 

[Rob Parker]

The error was because your extra textbox was using an expression which could
not be evaluated. All the data was not coming form one source - the bound
textboxes were using the form's datasource, and the unbound textbox was
using a different recordsource (your query). You cannot bind a control to a
field from a different recordsource to that of the form; ie you cannnot set
the controlsource to use a field from a query which is not the form's
recordsource. So, as I said in my original post, you could either use a
query (which has both the table fields and the calculated field) as the
form's recordsource, or you could do the calculation in an unbound control
in the form, using an expression which refers to fields in the form's
recordsource.

The only exception (and one that is in fairly common use - but not for
something as simple as you are attempting) is that you can use a domain
aggregate expression (eg. dLookup, dCount, dMax, ...) to display data from
a separate source. You can specify the criteria in the domain aggregate
function to use the record to which it is related. So, for example, if you
have an ID field in your table, you could use an unbound textbox with a
control source of:
=dLookup("Result","YourQueryName","ID = " & [ID])

But that's doing things the hard way in this case.

HTH,

Rob

Rob - thanks a lot for your detailed response.
That certainly explains why my simple test did not work, as you are right
I
had not bound the form itself to anything.
However, I was seeing the error originally in my app where the form was
bound to a table and I had taken two of the fields from that table into a
query, then added a calculated field and created an extra text box on the
form and bound that to the calculated field of the query. Given that all
the
data I was working with was coming from one and the same table, and given
that the form was bound to that, why would I have got the error there?
Thanks again for your help
CW

It sounds like your form is not bound to a recordsource, and you are
trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the
names
you have entered. Although it's possible to work with unbound forms,
it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and set
the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name
into
the box on the property sheet, or via the dropdown. Note that you do not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the form
bound to the table, with textboxes bound to Field1 and Field2, and in an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for
that
textbox. Another common trap, particularly if you set up your form via a
wizard or drag-and-drop fields, is to have a textbox with the same name
as a
field in the form's recordsource; if you enter an expression referring to
a
field with the same name as a textbox, you will also get a #Name error.
For
this reason, it's good practice to use a naming convention for all your
controls to avoid them having the same name as an underlying field (eg.
name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob

Whatever I do, I cannot pull a calculated field from a query into a
form
or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and
Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a calculated
field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text
boxes
and set the sources as Table1.Field1 and Field2, created a further
text
box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was that
you
could create a calculated field and then use it wherever you wanted???
Many thanks
CW

 

[Douglas J. Steele]

I can't remember the last time I linked a form to a table (if ever!). Using
queries for the recordsource is much more flexible, especially for ensuring
that the records are returned in the desired order.

Assuming you don't change the names of the fields between your table and
your query, you shouldn't have any issue with the control sources of your
existing controls.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

Ah - thanks Douglas that's a fairly fundamental point!
So if I have a bunch of forms that are currently bound to tables (as I do)
then I would need to write a query for each one that would include all the
necessary fields and change the recordsource for each form from the
existing
table to the new query, before I can hope to bring in any calculated
fields
that I may construct within those queries?
And presumably I would have to change the control source on every control
on
those forms, too?? Blimey, might as well start all over again!!
Would appreciate your confirmation re the action I need to take, thanks.
CW

Your form needs to be bound to the query, not the table.

The fact that the query is working with data from the same table is
irrelevant.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

Rob - thanks a lot for your detailed response.
That certainly explains why my simple test did not work, as you are
right
I
had not bound the form itself to anything.
However, I was seeing the error originally in my app where the form was
bound to a table and I had taken two of the fields from that table into
a
query, then added a calculated field and created an extra text box on
the
form and bound that to the calculated field of the query. Given that
all
the
data I was working with was coming from one and the same table, and
given
that the form was bound to that, why would I have got the error there?
Thanks again for your help
CW

:

It sounds like your form is not bound to a recordsource, and you are
trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the
names
you have entered. Although it's possible to work with unbound forms,
it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and
set
the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name
into
the box on the property sheet, or via the dropdown. Note that you do
not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the
form
bound to the table, with textboxes bound to Field1 and Field2, and in
an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for
that
textbox. Another common trap, particularly if you set up your form
via a
wizard or drag-and-drop fields, is to have a textbox with the same
name
as a
field in the form's recordsource; if you enter an expression referring
to
a
field with the same name as a textbox, you will also get a #Name
error.
For
this reason, it's good practice to use a naming convention for all
your
controls to avoid them having the same name as an underlying field
(eg.
name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob


Whatever I do, I cannot pull a calculated field from a query into a
form
or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and
Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a
calculated
field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text
boxes
and set the sources as Table1.Field1 and Field2, created a further
text
box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was
that
you
could create a calculated field and then use it wherever you
wanted???
Many thanks
CW

 

[Guest]

Douglas - thanks very much - looks like I have quite a bit of re-designing to
do!!
I'm very grateful for your help.
CW

I can't remember the last time I linked a form to a table (if ever!). Using
queries for the recordsource is much more flexible, especially for ensuring
that the records are returned in the desired order.

Assuming you don't change the names of the fields between your table and
your query, you shouldn't have any issue with the control sources of your
existing controls.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)

Ah - thanks Douglas that's a fairly fundamental point!
So if I have a bunch of forms that are currently bound to tables (as I do)
then I would need to write a query for each one that would include all the
necessary fields and change the recordsource for each form from the
existing
table to the new query, before I can hope to bring in any calculated
fields
that I may construct within those queries?
And presumably I would have to change the control source on every control
on
those forms, too?? Blimey, might as well start all over again!!
Would appreciate your confirmation re the action I need to take, thanks.
CW

Your form needs to be bound to the query, not the table.

The fact that the query is working with data from the same table is
irrelevant.

--
Doug Steele, Microsoft Access MVP

(no e-mails, please!)


Rob - thanks a lot for your detailed response.
That certainly explains why my simple test did not work, as you are
right
I
had not bound the form itself to anything.
However, I was seeing the error originally in my app where the form was
bound to a table and I had taken two of the fields from that table into
a
query, then added a calculated field and created an extra text box on
the
form and bound that to the calculated field of the query. Given that
all
the
data I was working with was coming from one and the same table, and
given
that the form was bound to that, why would I have got the error there?
Thanks again for your help
CW

:

It sounds like your form is not bound to a recordsource, and you are
trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the
names
you have entered. Although it's possible to work with unbound forms,
it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and
set
the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name
into
the box on the property sheet, or via the dropdown. Note that you do
not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the
form
bound to the table, with textboxes bound to Field1 and Field2, and in
an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for
that
textbox. Another common trap, particularly if you set up your form
via a
wizard or drag-and-drop fields, is to have a textbox with the same
name
as a
field in the form's recordsource; if you enter an expression referring
to
a
field with the same name as a textbox, you will also get a #Name
error.
For
this reason, it's good practice to use a naming convention for all
your
controls to avoid them having the same name as an underlying field
(eg.
name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob


Whatever I do, I cannot pull a calculated field from a query into a
form
or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and
Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a
calculated
field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text
boxes
and set the sources as Table1.Field1 and Field2, created a further
text
box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was
that
you
could create a calculated field and then use it wherever you
wanted???
Many thanks
CW

 

[Guest]

Rob -
A perfect detailed explanation, thank you SO much, I understand now.
I do appreciate the time you have given to helping me.
CW

The error was because your extra textbox was using an expression which could
not be evaluated. All the data was not coming form one source - the bound
textboxes were using the form's datasource, and the unbound textbox was
using a different recordsource (your query). You cannot bind a control to a
field from a different recordsource to that of the form; ie you cannnot set
the controlsource to use a field from a query which is not the form's
recordsource. So, as I said in my original post, you could either use a
query (which has both the table fields and the calculated field) as the
form's recordsource, or you could do the calculation in an unbound control
in the form, using an expression which refers to fields in the form's
recordsource.

The only exception (and one that is in fairly common use - but not for
something as simple as you are attempting) is that you can use a domain
aggregate expression (eg. dLookup, dCount, dMax, ...) to display data from
a separate source. You can specify the criteria in the domain aggregate
function to use the record to which it is related. So, for example, if you
have an ID field in your table, you could use an unbound textbox with a
control source of:
=dLookup("Result","YourQueryName","ID = " & [ID])

But that's doing things the hard way in this case.

HTH,

Rob

Rob - thanks a lot for your detailed response.
That certainly explains why my simple test did not work, as you are right
I
had not bound the form itself to anything.
However, I was seeing the error originally in my app where the form was
bound to a table and I had taken two of the fields from that table into a
query, then added a calculated field and created an extra text box on the
form and bound that to the calculated field of the query. Given that all
the
data I was working with was coming from one and the same table, and given
that the form was bound to that, why would I have got the error there?
Thanks again for your help
CW

It sounds like your form is not bound to a recordsource, and you are
trying
to refer to fields from different potential recordsources directly in
textboxes. That's not the way it works, and doing so will give #Name
errors, because there is no field in the forms recordsource with the
names
you have entered. Although it's possible to work with unbound forms,
it's
not usual - and it generally involves considerable amounts of VBA code
behind the scenes. Most often, a form is bound to either a table or a
query, and then the fields from that table/query can be accessed via
controls on the form.

For what you want, include both Field1 and Field2 in your query, and set
the
recordsource of the form to the query (enter the name of the query, or
select it via the dropdown in the property box). Then you can set the
control sources for your textboxes to Field1, Field2 and Result (the
calculated field in your query), again either by typing the field name
into
the box on the property sheet, or via the dropdown. Note that you do not
need an = sign before the field name.

It's also possible to do calculations on the form, by setting the
controlsource of a textbox to an expression. So you could have the form
bound to the table, with textboxes bound to Field1 and Field2, and in an
unbound textbox enter "=[Field1] + [Field2]" as the controlsource for
that
textbox. Another common trap, particularly if you set up your form via a
wizard or drag-and-drop fields, is to have a textbox with the same name
as a
field in the form's recordsource; if you enter an expression referring to
a
field with the same name as a textbox, you will also get a #Name error.
For
this reason, it's good practice to use a naming convention for all your
controls to avoid them having the same name as an underlying field (eg.
name
a textbox as txtField1, rather than using the default of Field1).

HTH,

Rob


Whatever I do, I cannot pull a calculated field from a query into a
form
or
report without getting a #Name? error.
I did the simplest of tests: created Table1 with fields Field1 and
Field2,
with format Number, Long Integer.
Created Query1, including those two fields and another, a calculated
field,
like this:
Result: [Field1]+[Field2]
Created Form1 (in Design View, not via the Wizard). Added two text
boxes
and set the sources as Table1.Field1 and Field2, created a further
text
box,
set the Control Source to be = Query1.Result.
I get #Name? in the controls in the Form.
Where am I going wrong? I thought the whole point of a Query was that
you
could create a calculated field and then use it wherever you wanted???
Many thanks
CW