Err 3270 "Property Not Found" on Open Report Preview

[pondside]

I have been putting together a set of reports that are driven by sql-driven logic composed within a form-based module. Some recent change in my logic has triggered the 3270 "Property Not Found Error" when the report is opened for preview with the following line:

DoCmd.OpenReport strReportName, acPreview

Previous versions of my logic were working fine, but after a set of recent changes, suddenly this. To what is the message referring? I understand properties in general, but more specifically, how do I determine what property is not found, and does it mean in my report, my form, underlying tables, code? Is there some way to interrogate the system about at least the general location of the problem property?

 

[Dalain]

When your code erros, place your curser over the
DoCmd.OpenReport strReportName, acPreview

And check, does strReportName = "CorrectSpellingYourReportName"
and does acPreview = 2.

If both values are correct, try going to the reports In the DB Window and doing a preview of your report there. If it does not work, then the problem is the report itself and not the OpenReport command.

Hope this helps
Dalain

 

[VBslammer]

it should be [tt]acViewPreview[/tt]

VBSlammer

Unemployed in Houston, Texas

 

[pondside]

Thanks to both of you for your responses... they helped me think of some new approaches, and I have discovered that the sticking point is connected to the Report's sorting and grouping box.
I use sort strings built into the SQL Select string placed in the Report's RecordSource. These work correctly in my earlier version. As soon as I add a Group Footer to the report, in order to support counts and totals, I get the 3270 error. If I remove the footer and delete the group, the error goes away.
Does this suggest to you what I am doing wrong here? I have other reports that successfully use this combination, so I don't see what's different, nor can I figure out what property the error is upset about.

 

[Dalain]

VBslammer is right, it should be acViewPreview. Sorry I missed it.

The fact that the Group Footer added or removed changes the error. I would try more detailed step by step approach. (Process of elimination)

First make a copy of your report.

Using your Copy. Add your Group Footer.
Now I am assuming that you have numerous fields and or code associated to the Group Footer.
Do a Print Preview. (You should get your error code 3270)

Now for the Step by Step. Delete one of your fields or other items associated with the Group Footer , then do another Print Preview.

If every thing goes to plan, you will eventually be able to do a Print Preview with NO errors, which mean the last item you removed was causing the error. Take a look at your original Report and check that item to figure out why the error is being caused, now that you know where its being caused.(the sticking point as you called it) You could also make another copy of the report and delete only that item and see if the error is still there.

Hope this helps

Dalain

 

[pondside]

Dalain,

Your words to the original problem described here months ago, prompted me then to take evasive action along the lines you suggested, and I eventually found a dodge changing one of the footers to get around the difficulty without ever figuring out the cause.

In the last week it came back, with another form and report, and no dodge seemed to work. I finally stuck to my experiments and discovered that my prepared SQL string had a syntax problem. The SQL string included the following:

" WHERE (((tblGrd.lngDID)=
Forms!frmReportPick.cboDID.Column(0)) "

This drew the 3270 Property error. I changed the string to:


" WHERE (((tblGrd.lngDID)=
Forms!frmReportPick.cboDID)) "

and the problem went away. I confess I do not understand why the reference to a specific column on the CBO, which is valid enough in other contexts, appears to be invalid here.

But I am documenting this because the message is so vague it led me to explore all manner of possibilities in the various headers and footers of the report, never suspecting it was buried somewhere in my SQL. Hopefully this will help others who might run into similar snags.

 

[Dalain]

Thank's for your update, it is always nice to know if the tips we gave were helpfull.

dalain