Msgbox Parent![fieldname] produces error even though...

[MatthewGrace]

Thank you for considering my post. It's been a LONG time since I've used Access.

I have a Report with a Recordsource of SELECT Businesses.id, Businesses.name FROM Businesses;
No problem. Only 2 fields.

So I have a subreport on that Report. It has a command button whose purpose is to read those 2 fields.

When I press the button, this line works:
MsgBox Parent![id]
and get a perfect response.

But the next line does not:
Msgbox Parent![name]
produces error 2465: "Cannot find the field 'name' referred to in your expression."

It all looks so straightforward. What could I be missing?
Matt

[Micron]

could be because
a) name is a reserved word but you have it enclosed in [ ] so maybe not
b) reports are not meant to be interactive - sub reports even less so.
Maybe explain why you think you need interaction on a report that should be left to forms.

[moke123]

Do you have bound controls on the parent report?

I just tried duplicating your problem.

a report with a recordsource and 2 controls (ID and Name) and a subreport with a button.
In the click event - msgbox Parent!Name

this works fine.

If I remove the 2 controls and leave the recordsource I get error 2465.

[Micron]

But Parent!Name is not the same as Parent![Name] as Name would be the name property of the Parent object?

Besides, to me this looks like the code is in the subreport module (that's where the button is?), which has no parent named [Name], nor does it have a control named [Name]?
I still think that interacting with a report is questionable.

[MatthewGrace]

You're right: [name] is a reserved word. Even though I had it enclosed in [ ], Access doesn't like that. Simply renaming the field to something other than name fixed it.

As for why the blazes I would have interaction on a Report and not a Form: the short answer is that I already had a beautiful Report working and I just wanted one tiny bit of button interactivity to make life easier. it's been years since I've played with VBA meaningfully, so I figured this was less intimidating than creating a complex form from scratch.
Thanks Micron!

[Micron]

Hah! All that guessing about Parent stuff for nothing. In the future, refer to this.

Also, if you adopted a naming convention, you would likely never have this sort of thing happen.
F'rinstance when it comes to fields, FName (or FirstName, etc) but never First Name or Name. Same with variables if you always preface them with some sort of 'type' prefix such as lngCount but never Count. lng should tell anyone that lngCount is a long, even 100 lines of code down.

EDIT - I'm kind of surprised you didn't get away with it when it was bracketed.

[MatthewGrace]

I tested the exact same situation in a Form/SubForm... it worked. There was no screaming about the reserved word 'Name' as was the case with Report/SubReport. Hm.

Now Moke123 was right in what he said: If the Parent report has bound controls for the fields in question, it seems to work... sometimes. If you delete those controls you're definitely getting a 2465 error.

@Micron: Yes the word "name" is a terrible choice for a field name. I would never do that. I'm connecting to Linked Tables online others made in MySQL/PHP backend for a TypeScript (that terrible excuse for a language) Front end. I've worked with many of them. Their abilities are light-years ahead of what mine are/were.

But I got soooo sick and tired of paying these programmers to make forms and reports and features for my online order forms that would be cake in Access for an intermediate level programmer. It's really disheartening to see thousands of very complex lines of code online in what we see as MS Access basics. This is why I so badly wished MS made a realistic tool for building Access stuff online. There would be no need for most of these other web languages.

So now I'm just creating a tool to display all the reports myself in Access

Matt

[Micron]

Well that's odd because I threw a subform with a button onto a main form and when I click I get the error with or without the brackets...
MsgBox Parent![Name]

EDIT - As soon as I posted that, I thought of something. What if I use Parent.Name
It works, and I know why yours failed. Want to take a guess while I have coffee?

EDIT2 - coffee break done. Now it's time for lunch! I see that you're still off-line so I'll give you a chance to figure it out for yourself.

[moke123]

I used the dot and bang also so I already knew the answer.

[Micron]

OK so no guess. Without looking it up (using my own words)
The bang (!) causes Access to pass what follows it as the Name argument (string) to the default member of what proceeds it. Me preceded it, and since Me refers to a form or report, then the default member of a form/report is Controls. So you were passing the word Name as the name of a control. Since there is no such control named "Name" then you got a message telling you that it could not find a field (control) by that name.

Further to the use of ! one should know that Me!txtName will not be evaluated until run time; i.e. when you compile your code it is not evaluated. Thus if it is incorrectly spelled it will fail and raise an error when the line is executed. Why use the ! at all then? For me, the only time it seems to be the norm is when referring to a recordset field by name. If there is case for using late bound access to a default member, I have never encountered it.