MS Access Forum / General 2 / May 2007
Error when trying to use calc field from Query
|
|
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
|
|
|