current record PDF issues

[Pat Hartman]

I don't like Dwane's method because it temporarily changes a permanent object.

I don't know your application but ONE method is to add a hidden field to the form that opens the report. To make this work, you need to do two things.
1. Change the RecordSource query of the Report to add a where clause that references the hidden form field:

Where SomePK = Forms!myform!myPK

2. When you click on the print report button, copy the PK of the record you want to show to the hidden field.


This method is simple and works fine (also delete the OpenReport in your current code because it is not necessary and just adds unnecessary overhead) -- unless you want to open the same report from multiple forms. In that case, you can use a Tempvar instead of a form control reference.

 

[DHookom]

With the code I suggested with the code in the link, it’s very easy to reset the SQL to the original. You can also build a fairly sophisticated where clause, apply it, and call it from any form.

Using a control on a form limits you to having that form open and setting the correct value.

 

[Gasman]

You have two lines.

The first one opens the report for Preview on-screen. It contains a filter: "EWNID=" & Nz(Me.EWNID, 0)

The second one sends another copy of the report to PDF. This is a different copy of the report, not the one just opened for Preview on-screen. It has no filter. Add your filter to this second line that sends the other copy to PDF.

No so George.

With code

Sub PrintOneRecord()
DoCmd.OpenReport "rptPressure", acViewPreview, , "PressureID = 13", acHidden
DoCmd.OutputTo acOutputReport, "rptpressure", acFormatPDF, "f:\temp\ReportTest.pdf"
DoCmd.Close acReport, "rptpressure"
End Sub

Result

 

[Pat Hartman]

it’s very easy to reset the SQL to the original.

I really hate to argue with you about this but I really think that there are simple methods to solve the problem without actually renaming permanent objects temporarily. You never know who is going to modify the code in the future. Will they notice that a permanent object was changed? Will they make a change that interferes with resetting the query back to its original state? Just too risky for my taste. It also reminds me of a database I was once called in to change. Seemed simple enough. Five minutes Change the report to add the new column. I located the report object. I changed it. Tested it immediately. It worked. Went back and ran the code from the button on the form and the column was missing. Duh? Thinking I'd lost my mind, I did it again. Same result. I'll leave it to you to figure out the problem. I was pretty new to Access even though I was an experienced programmer so it took me longer to suss out what was going on than it would now because it never occurred to me that anyone would replace the report I was trying to run using VBA. What I found was the the original developer didn't know how to use the WHERE argument of the OpenReport method to alter the selection criteria and so his solution was to make two copies of the report. Then copy the dummy he wanted to use and give it the "common" name so he could run the modified version using the common name. Not exactly what you are recommending but pretty close and a definite trap waiting for the unwary.