Subform Print Problem

[drvice]

I have a messy problem I've been working on and have made something
almost work, but have run into a snag.

Here's the issue:

I've been tasked with building a "report" that is about 3 pages long.
The requirement is that this "report" will pull data from access
tables to fill some of the fields on the "report" and some of the
fields will remain blank. All fields need to be editable so the user
can change them before the "report" is printed.

In order to accomplish this, I've created a form. Unfortunately, the
form is larger than 24", so I created a 2nd form to house the rest of
the fields. I added this 2nd form to the first form as a subform. So
far, so good...

To load the data, I first ask the user for input using a few
InputBox's and dynamically alter the SQL of a query using a QueryDef
(setting the SQL parameter). I then use a ADO recordset to pull the
data out of the edited query, and populate the textboxes in the forms
(each form uses it's load event to pull it's data into it's fields).
Again, it works.

Here's where the problem comes in. When I Print Preview the form, the
data is all there. When I to the actual print to the printer...the
data in the subform is gone.

Has enyone seen this problem or know how to fix it?

Thanks in advance.

Dan

 

[Jeanette Cunningham]

Yes,
it is a common failure when trying to print a subform - in other words
access does not print data on subforms.
However if you use a report instead of a form, access will print a
subreport.
Bottom line is that reports are meant to be printed and have features to
help with printing but forms do not.
Users edit data on the form, when they push the print button, you have code
that opens the report for that data and prints the report.

Jeanette Cunningham

 

[Chris Reveille]

Forms are or viewing and editing data. They do not print well. Use reports
and subreports.

 

[drvice]

Chris/Jeanette,

Thanks for your assistance...

I first tried reports, but one of the requirements is that the user
can edit the data in the "report" before they print it. I don't
believe I can do this with a report. This is why I went with a form.

Is there a way to "get around" the form height limitation so I don't
have to use a sub-form?

Dan

 

[drvice]

Chris/Jeanette,

Thanks for your assistance...

I first tried reports, but one of the requirements is that the user
can edit the data in the "report" before they print it.  I don't
believe I can do this with a report.  This is why I went with a form.

Is there a way to "get around" the form height limitation so I don't
have to use a sub-form?

Dan

Also, Jeanette...

I see where you say:

"Users edit data on the form, when they push the print button, you
have code
that opens the report for that data and prints the report. "

This is not an option because the data is not being written back to
the database (the fields are unbound...I bind them in code with a
recordset).

I guess, if I can't do it all with a form, I'm going to have to
explore the possibility of saving the data from the form to a table
just so I can open a report for printing.

Dan

 

[Paul Shapiro]

You can have your report read the unbound data from the form. The control
source on the report would be something like:
=Forms!myFormName.controlName.value

The form would have a button to open the report. The report should verify
the form is open, or you'll have an error referencing the form controls.

Chris/Jeanette,

Thanks for your assistance...

I first tried reports, but one of the requirements is that the user
can edit the data in the "report" before they print it. I don't
believe I can do this with a report. This is why I went with a form.

Is there a way to "get around" the form height limitation so I don't
have to use a sub-form?

Dan

Also, Jeanette...

I see where you say:

"Users edit data on the form, when they push the print button, you
have code
that opens the report for that data and prints the report. "

This is not an option because the data is not being written back to
the database (the fields are unbound...I bind them in code with a
recordset).

I guess, if I can't do it all with a form, I'm going to have to
explore the possibility of saving the data from the form to a table
just so I can open a report for printing.

Dan

 

[drvice]

You can have your report read the unbound data from the form. The control
source on the report would be something like:
    =Forms!myFormName.controlName.value

The form would have a button to open the report. The report should verify
the form is open, or you'll have an error referencing the form controls.








Also, Jeanette...

I see where you say:

"Users edit data on the form, when they push the print button, you
have code
that opens the report for that data and prints the report. "

This is not an option because the data is not being written back to
the database (the fields are unbound...I bind them in code with a
recordset).

I guess, if I can't do it all with a form,  I'm going to have to
explore the possibility of saving the data from the form to a table
just so I can open a report for printing.

Dan

Paul,

This sounds like it will work for me. My only question would be...can
I reference the data on the subform from the subreport? Would it be
the same control source: =Forms!mySubFormName.controlName.value ?

Dan