Report not printing correctly....

  • Thread starter Thread starter Paul Laska
  • Start date Start date
P

Paul Laska

Hi All,

You may notice this one from yesterday. I have also
received some emails, and there are now a few of us with
the same problem. Could someone please help?

I have a main report with about 12 subreports, 4 of these
subreports each have 1 subreport of their own. The main
report, in the Open Event, grabs a global variable and
replaces a parameter in the query.SQL that is it's
RecordSource with the value, so that I don't have to
prompt the user for the parameter. The global variable
is stored in a Private member variable. I expose the
member variable through a Public Property Get function,
which all the subforms retrieve so that they can alter
their RecordSource query.SQL in a similar fashion. The 4
subreports with a subreport of their own operate in a
similar fashion.

This all works fine, and when I Preview the report
everything looks good. However then I hit the Print
button, and what comes out is only the information
directly on the main report. If I goto the Database
window, highlight the report, and select print (without
previewing the report) everything prints just fine.

Does anyone have any ideas?
Thanks.

Paul Laska
 
Paul,

I will get a chance to look at this in more detail later. In the
meantime... *how* and *when* does the value of the global variable get
assigned?

- Steve Schapel, Microsoft Access MVP
 
Hi Steve,

The global variable gets set during the OnClick event of
the "Print All Data" button. As for how, the value is
taken from an ADO.Recordset object that I am using to
drive Form1, which has a bunch of unbound controls.

Thank you.
Paul Laska
 
Paul,

To some extent, I think I have misunderstood an aspect of what you are
doing. I imagined that your report was based on a saved query. It
seemed to me that if you were assigning a value to a global variable,
then this value must be coming from "somewhere", so why not just refer
to it in the query criteria using syntax such as
[Forms]![Form1]![Table1PrimaryKey]? Then, your subreports are
apparently also using this value as a selection criteria. That means
these subreports must also be including the same field in their
recordsources. Therefore, if the LinkChildFields/LinkMasterFields
properties of the subreports was to include this field, and the
recordsource of the main report is being restricted to a specific
value in this field, then there would be no need to apply the
criterion to the recordsources of the subreports. Apologies if this
is off-beam based on any further misunderstanding of what you are
really doing.

As regards the other question about the toolbar buttons, no I don't
know how to control the behaviour of the basic Access toolbars,
although I think it is possible. However, if you make a custom
menubar or toolbar, you can assign any code you like to the
functionality of the buttons.

- Steve Schapel, Microsoft Access MVP
 
Hi Steve,

I think you actually have a pretty good grasp of what I'm
trying to convey. The query underlying the report is a
saved query. However, to provide the data for the
query's parameter criteria: in the report's Open Event I
retrieve the SQL statement from CurrentDB.QueryDefs
(Query2).SQL, replace the '?' parameter character in the
SQL statement, and set the RecordSource for the report to
the modified SQL statement. The data that is being
supplied through the global variable comes from the
ADO.Recordset that I use to drive Form1 with the unbound
controls.

So part of the problem of refering to Table1.PrimaryKey
in the Query, is the question of what to refer to as the
parent object/collection, since the data comes from the
ADO.Recordset variable in Form1's code module.

In a scenario with a bound form I could see using [Forms]!
[Form1]![Table1PrimaryKey]. Unfortunately this is not my
case. ADO was chosen to avoid having every record
transmitted across the network, just to be processed by
the local Access Jet/SQL engine and have most of the
records thrown away. With ADO we were told that when we
send the SQL statement, the Server side, be it an Access
MDB or SQL Server, would process the SQL command, and
only transmit the requested records back across the
network. I realize the report won't follow this
conservation of network resources, but it shouldn't be
run often enough to be a problem. An Access MDB was
chosen as the initial test database, and in the future
SQL Server may be purchased and used for some of the
larger sites once the application is proven viable, but
Access MDBs will still be used at the smaller sites
(Otherwise I would push for using an ADP application,
which I know uses ADO as the native format).

Probably more information than you wanted, but it
explains some of the quirks I'm trying to work through on
this "simple prototype" they want. ;-)

Another question I've been trying to find the answer to
is, does Access 2002 support ADO as a native Recordset
object for Forms in an MDB? If it does, then I could
recommend they use that instead of Access 2000, and
simplify this whole process by using bound forms. And by
using bound forms I could possibly in turn use references
in my queries like the one you suggested for the
parameter.

Thanks again.
Sincerely,
Paul Laska

-----Original Message-----
Paul,

To some extent, I think I have misunderstood an aspect of what you are
doing. I imagined that your report was based on a saved query. It
seemed to me that if you were assigning a value to a global variable,
then this value must be coming from "somewhere", so why not just refer
to it in the query criteria using syntax such as
[Forms]![Form1]![Table1PrimaryKey]? Then, your subreports are
apparently also using this value as a selection criteria. That means
these subreports must also be including the same field in their
recordsources. Therefore, if the LinkChildFields/LinkMasterFields
properties of the subreports was to include this field, and the
recordsource of the main report is being restricted to a specific
value in this field, then there would be no need to apply the
criterion to the recordsources of the subreports. Apologies if this
is off-beam based on any further misunderstanding of what you are
really doing.

As regards the other question about the toolbar buttons, no I don't
know how to control the behaviour of the basic Access toolbars,
although I think it is possible. However, if you make a custom
menubar or toolbar, you can assign any code you like to the
functionality of the buttons.

- Steve Schapel, Microsoft Access MVP


Hi Steve,

The global variable gets set during the OnClick event of
the "Print All Data" button. As for how, the value is
taken from an ADO.Recordset object that I am using to
drive Form1, which has a bunch of unbound controls.

Thank you.
Paul Laska
Click to expand...

.
Click to expand...
 
Back
Top