expression in unbound textbox

[tina]

hi folks,

i'm using Access97 running in Win2K Pro O/S. i have a query based on a
table, with a calculated field made up of the concatenated first, middle,
and last name fields in the table, and aliased as EName. the query has
criteria set on the employee table's primary key, and returns records for
only a single employee. the name shows up as expected when i run the query.

i used this query as the base for a crosstab query, including EName as a
RowHeading field. again, the name shows up as expected when i run the
crosstab query.

then i based a report on the crosstab query. in the PageHeader section, i
added a textbox bound to EName, and the name shows up as expected in Report
Preview. then i changed the textbox ControlSource to

= "for " & [EName]

also changing the control's name, of course, and in Report Preview the
control displays

for 1

(1 is not the primary key value of the employee record, by the way - in my
test, the primary key value is 72.)

i've tried changing the textbox to a label control, and setting its' Caption
property in the Open event, and then in the PageHeader section's OnPrint
event - the label comes up blank in Report Preview.

i've also tried grouping on the EName field, and putting the bound textbox
in that GroupHeader section. as a bound control, the textbox displays the
value of EName, as expected; but again, when i change it to a calculated
control (renamed) with the ControlSource set as noted above, i get the same
display as noted above. in both calculated control tests, i also tried
adding a separate textbox control, bound to the EName field, to the same
section containing the calculated control. in both instances, the bound
control displays the EName value as expected, while the calculated control
in that same section displays

for 1

i am at a loss as to why this is happening, and how to fix or get around it.
any suggestions will be appreciated.

tia, tina

 

[Ken Snell \(MVP\)]

Be sure that that the textbox is not named EName (from when you first put it
on the report).

Haven't seen this type of behavior before, but try this to see what happens:
Go back to the textbox being bound to EName, and make it invisible. Add a
new textbox that has this expression as the ControlSource:
="for " & [nameofENametextbox]

 

[tina]

Be sure that that the textbox is not named EName (from when you first put it
on the report).

yes, i took care to avoid the circular reference.

Haven't seen this type of behavior before, but try this to see what happens:
Go back to the textbox being bound to EName, and make it invisible. Add a
new textbox that has this expression as the ControlSource:
="for " & [nameofENametextbox]

yes, that works - though heaven only knows why the direct reference to the
field within the calculated control does not. like you, i've never seen this
type of behavior in a calculated control on a report (or a form, for that
matter) before.

thanks, Ken!

--

Ken Snell
<MS ACCESS MVP>

hi folks,

i'm using Access97 running in Win2K Pro O/S. i have a query based on a
table, with a calculated field made up of the concatenated first, middle,
and last name fields in the table, and aliased as EName. the query has
criteria set on the employee table's primary key, and returns records for
only a single employee. the name shows up as expected when i run the
query.

i used this query as the base for a crosstab query, including EName as a
RowHeading field. again, the name shows up as expected when i run the
crosstab query.

then i based a report on the crosstab query. in the PageHeader section, i
added a textbox bound to EName, and the name shows up as expected in
Report
Preview. then i changed the textbox ControlSource to

= "for " & [EName]

also changing the control's name, of course, and in Report Preview the
control displays

for 1

(1 is not the primary key value of the employee record, by the way - in my
test, the primary key value is 72.)

i've tried changing the textbox to a label control, and setting its'
Caption
property in the Open event, and then in the PageHeader section's OnPrint
event - the label comes up blank in Report Preview.

i've also tried grouping on the EName field, and putting the bound textbox
in that GroupHeader section. as a bound control, the textbox displays the
value of EName, as expected; but again, when i change it to a calculated
control (renamed) with the ControlSource set as noted above, i get the
same
display as noted above. in both calculated control tests, i also tried
adding a separate textbox control, bound to the EName field, to the same
section containing the calculated control. in both instances, the bound
control displays the EName value as expected, while the calculated control
in that same section displays

for 1

i am at a loss as to why this is happening, and how to fix or get around
it.
any suggestions will be appreciated.

tia, tina

 

[Ken Snell \(MVP\)]

yes, i took care to avoid the circular reference.

Thought you would have done that, but I mentioned it for the "lurkers" < g

.

Haven't seen this type of behavior before, but try this to see what happens:
Go back to the textbox being bound to EName, and make it invisible. Add a
new textbox that has this expression as the ControlSource:
="for " & [nameofENametextbox]

yes, that works - though heaven only knows why the direct reference to the
field within the calculated control does not. like you, i've never seen
this
type of behavior in a calculated control on a report (or a form, for that
matter) before.

It's possible that a decompilation of the database might fix this problem...
appears as if the report thinks EName is also the name of something else?
But I must admit that I've found many instances where, in a report, I've had
to bind a control to a field, make that control invisible, and then use that
control in a ControlSource expression instead of using the field name
directly. Seems as if the report cannot "find" the field otherwise. But the
value of 1...now that makes me think the report is remembering another
"identity" for EName, but I am hard-pressed to explain why it would do that
and not throw the #Name? error too?

thanks, Ken!

You're more than welcome.