For years I have been inserting text fields in unbound forms to show field data by way of a calculated field...or combinations of fields. Now, all I get is the ubiquitous "#Name?" error message. None of the no-nos in the Help program for that error apply. Any ideas?? TIA
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations IamaSherpa on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Calculated fields in unbound form
- Thread starter jfhewitt
- Start date
- Thread starter
- #3
When I encountered this problem, I created a small test table. Name, address, etc. I then opened an unbound form, and inserted a text box control, containing the expression =[firstname]. I get the #Name error. I have been using this method for years, and never had a problem. Using Access 97. The Control Source is "=[firstname]" and the data source is the address table. Any ideas?
On the one hand you say it's an unbound form, which means that the Record Source is blank, and on the other you say the "data source" is the address table. I assume by the "data source" you mean the Record Source, since the field has to come form somewhere. So I think it's a mistake to call this an unbound form. That's what threw me in your original message.
Oddly, when I tried this with Access 97 using the Form Wizard, I got #Error, not #Name. Then when I created the form from scratch, it worked.
Next I copied the control from the form that gave me #Error and pasted it on the form that worked, alongside the existing control. Then both of the controls gave me #Error. I deleted the pasted control, and the original one worked again! Bizarre!
Ok, I've figured it out now. When I use the Form wizard, it names the control the same as the field name, so =[Data1] refers to the control, not the field. That's why #Error. Could that be why you're having the problem? Rick Sprague
Oddly, when I tried this with Access 97 using the Form Wizard, I got #Error, not #Name. Then when I created the form from scratch, it worked.
Next I copied the control from the form that gave me #Error and pasted it on the form that worked, alongside the existing control. Then both of the controls gave me #Error. I deleted the pasted control, and the original one worked again! Bizarre!
Ok, I've figured it out now. When I use the Form wizard, it names the control the same as the field name, so =[Data1] refers to the control, not the field. That's why #Error. Could that be why you're having the problem? Rick Sprague
- Thread starter
- #5
OK..we're getting "Record Source" (blank in an unbound form) and "Control Source" in the control properties confused. My form record source is blank...it is not bound to any table (I do this so that no data remains when the form is closed). The Control Source for the text box control contains a reference to a table field, in this case say [firstname]. I've got fifteen other databases with calculated controls containing references to table fields...and formulae from data in table fields. On this form, I put in a check box and a text box containing a formula based on the check box...no problem. MSKB refers to a similar problem when trying to use a caculated control in another calculation...but that's not a problem. This so weird...I even reinstalled Access to see if there could be a registry problem, but no change. I'm getting some errors, also, but mostly #Name. Really baffling. I'm going to figure this out...someday.
Actually, I've has a somewhat similar problem with reports getting #Name errors. I finally figured out that it was because I had a field name that duplicated a property name, and Access got confused about which one I was referring to. That's one thing you should check.
But something isn't making sense to me. Control Source properties can contain the name of a field in the form's recordset, or a formula. If your form is unbound (Record Source is blank), it doesn't have a recordset, so that's out. But to reference a table field in a formula, you'd have to somehow specify the table or query name, and which record you wanted. You can't just give a field name, because Access wouldn't know which table to look in, nor which row to read. Yet you say you've done this many times in the past. It doesn't make sense to me.
Also you said you left the form unbound "so that no data remains when the form is closed." Remains where? When the form is closed, it's destroyed--nothing could possibly remain there. And the data is actually "in" the table, anyway, not in the form. The form is just a view into the table; no data actually gets moved (as opposed to copied) from the table to the form. I think you might have a misconception about how forms relate to tables. I was wondering why you wanted to use unbound forms to display table data, when using a bound form would be much easier. Rick Sprague
But something isn't making sense to me. Control Source properties can contain the name of a field in the form's recordset, or a formula. If your form is unbound (Record Source is blank), it doesn't have a recordset, so that's out. But to reference a table field in a formula, you'd have to somehow specify the table or query name, and which record you wanted. You can't just give a field name, because Access wouldn't know which table to look in, nor which row to read. Yet you say you've done this many times in the past. It doesn't make sense to me.
Also you said you left the form unbound "so that no data remains when the form is closed." Remains where? When the form is closed, it's destroyed--nothing could possibly remain there. And the data is actually "in" the table, anyway, not in the form. The form is just a view into the table; no data actually gets moved (as opposed to copied) from the table to the form. I think you might have a misconception about how forms relate to tables. I was wondering why you wanted to use unbound forms to display table data, when using a bound form would be much easier. Rick Sprague
- Thread starter
- #7
Rick:
There are numerous reasons I use unbound forms, but none really relevant. Since there can be a problem of the specific field of a specific table, I always use the expression builder to get the correct path. Its been a while since I've done any of this, and I'm sure I'll figure it out. It may relate, as you suggest, to identifying the table and field and the record to display. Thanks.
There are numerous reasons I use unbound forms, but none really relevant. Since there can be a problem of the specific field of a specific table, I always use the expression builder to get the correct path. Its been a while since I've done any of this, and I'm sure I'll figure it out. It may relate, as you suggest, to identifying the table and field and the record to display. Thanks.
- Status
