Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 2 / May 2007

Tip: Looking for answers? Try searching our database.

Error when trying to use calc field from Query

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
CW - 30 May 2007 09:25 GMT
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 - 30 May 2007 10:02 GMT
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
[quoted text clipped - 14 lines]
> Many thanks
> CW
CW - 30 May 2007 11:03 GMT
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
[quoted text clipped - 48 lines]
> > Many thanks
> > CW
Douglas J. Steele - 30 May 2007 11:43 GMT
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.

Signature

Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(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
[quoted text clipped - 77 lines]
>> > Many thanks
>> > CW
CW - 30 May 2007 12:49 GMT
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.
>
[quoted text clipped - 82 lines]
> >> > Many thanks
> >> > CW
Douglas J. Steele - 30 May 2007 13:15 GMT
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.

Signature

Doug Steele, Microsoft Access MVP
http://I.Am/DougSteele
(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)
[quoted text clipped - 114 lines]
>> >> > Many thanks
>> >> > CW
CW - 30 May 2007 15:34 GMT
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
[quoted text clipped - 122 lines]
> >> >> > Many thanks
> >> >> > CW
Rob Parker - 30 May 2007 12:58 GMT
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
[quoted text clipped - 77 lines]
>> > Many thanks
>> > CW
CW - 30 May 2007 15:36 GMT
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
[quoted text clipped - 104 lines]
> >> > Many thanks
> >> > CW
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.