I got a form associated with a report. Depending on the fields filled in the form the report has to add some extra things, ej.: if the user chooses "A" in some field, let's say [options] field of the form, the report has to show "you choose A this time" in the [options] report's field, and "it's a good choice" in other field in the report, let's say [explanation] field.
I've used the openreport method in vba and playing around with the where statement or the openargs
docmd.openreport "myreport", acViewPreview, , "[options] = " & "you choose " + [forms!].[options!] + " this time"
But i don't need to do a query to fill the report, so the where condition doesn't fit my need. Also with openargs nothing happens, maybe i'm getting something wrong.. Does someone has an idea of how to make it work with openargs or with another method?
There may be a simpler solution, but you can insert your user's choices into a 1 row table. Then use that table as a recordsource for your report.
An advantage of this approach is that, since your report will have a stable data source (table), it's a little easier to develop.
Related
Looked everywhere for help on this; I can't believe that there's no way it can be solved:
Scenario: I have an unbound subform that displays data in a datasheet. The user selects a report to display from a combo box and a query is generated on the fly then displayed in the subform. The user may then export the report (from the querydef) to an xlsx format file for distribution to colleagues. All works well.
However, the user also refines the data in the datasheet, selecting and sorting using the column controls. The question is: how do I export the refined data?
I'd be very grateful for any help. Thanks
All the selecting and sorting of the datasheet is stored in the me.filter property of the subform.
So you take the filter and hand it over to the report. You can use the filter just like a normal WHERE-clause of a SQL query.
[the name of the SubForm container control in the host form].Form.Filter = the where clause
EDIT: Here is some code that you use in the main form preferrably in the procedure that kicks off the creation of the report:
dim strWHERE As String
strWHERE = Me.subform.Form.Filter
docmd.OpenReport "YourReport", , , strWHERE
Pls give us feedback if it works.
I have a report (ReportX) that I wish to open from two different forms (FormA and FormB) in my database. I wish to do this because FormA and FormB address different aspects of my data, even if they ultimately get to the same output. ReportX is based on data from QueryX.
The problem I have is that QueryX would ideally filter the data based on the current RecordID in the current form. But I don't know how to accomplish this. I'd like to design QueryX so that the criteria for RecordID is essentially CurrentForm!RecordID, but research suggests that I cannot do this. Must I make separate but otherwise identical queries and reports for each form? Or is there a way to use VBA to define the query criteria when I click on the OpenReportX command button?
I already tried using the WHERE condition in the OpenReport command:
DoCmd.OpenReport "ReportX", acViewPreview, ,"RecordID = " & RecordID
but that did not display the results I wished. I need the report header to display/print for each RecordID and the page count in the page footer to reflect only the current/total pages of the RecordID in question. (In other words, if record 1 is one page, record 2 is two pages and record 3 is three pages, then ReportX, when displaying the first page of record 2, should say "Page 1 of 2" and not "Page 2 of 6.") So being able to display and print a single record properly using record filters would also solve my problem.
Which is the least cumbersome/most possible solution?
You should be able to accomplish this using the WHERE condition argument when you open a report:
DoCmd.OpenReport "rptName", acViewPreview, ,"RecordID = " & Me!RecordID
In the case where a I need more control over a Report's recordsource than what the Where condition argument can do for me, I will set the Reports RecordSource to be blank (after designing the report). Next I write code create the correct SQL statement in the Open Report button's Click event, followed by code to open the report and pass in the SQL as an opening argument for the report.
Private Sub cmdOpenReport_Click()
Dim sSQL as string
sSQL = "SELECT * FROM tblWhatever WHERE RecordID = " & Me!RecordID
DoCmd.OpenReport "rptReportName", acViewPreview, , , ,sSQL
End Sub
Then in the report's Open event I write code to set the recordsource:
Private Sub Report_Open(Cancel As Integer)
If IsNull(Me.OpenArgs) = False Then
Me.RecordSource = Me.OpenArgs
End If
End Sub
If neither of those accomplish what you want then you have an issue of a different sort. It's a little difficult for me to understand why you need All Records to show up in the header but only one record in the detail area. And how you expect to accomplish this. You might be best off trying to write a query first that gives you the exact results that your looking for so you know that it can be done.
As a side note, I actually use very few saved queries in my designs. It's not that there's anything wrong with using them, as the option is there for your convenience. I frequently use raw SQL on both forms and reports and set the RecordSource to the SQL on the Form or Reports Open or Load events.
Yes you can point to form data items in a query, and subsequently use that query in a report. The forms need to be open before the report runs. As far as having a header for each record, that is controlled in the settings of the report and how it displays the data.
In the Field, or Critera you can use the format:
[Forms]![frm_Process_Candidates]![QuestionTemplate]
Where frm_Process_Candidates would be the name assigned to your form, and QuestionTemplate is either the name of a control on your form, or a field from the data source of your form.
If you have a sub-form, there will be another [Form] call in the middle there.
[Forms]![frm_Dropdown_Admin]![frm_Dropdown_Admin_Detail].[Form]![text22]
Access should figure it out from there.
I have a text field with a button that filters by a keyword in a form.
Private Sub Command93_Click()
Me.Filter = "(Review Like '*" & Me.Text94 & "*')OR (Status Like '*" & Me.Text94 & "*')"
Me.FilterOn = True
Me.Requery
End Sub
I then have a button that generates the report from that filter.
Private Sub Filter_Click()
DoCmd.OpenReport "rptName", acViewPreview, , Me.Filter
End Sub
The problem is that whenever I hit this button to generate the report, I get a pop up box asking me to Enter Parameter ID and it is asking this for review. If I take the review criteria out (by the way I have many more fields I just used review and status to illustrate the example) then the report generates without any pop up box. The review is part of a notinlist event which opens another form and stores that info in a table review, if that is relevant at all. The report will still generate when I click ok and leave the Enter Parameter ID box blank but I'd like to somehow bypass it for two reasons - the first being the fact that I need other people who are not familiar with access to be able to use it and the second is the idea that if I learn what is causing it I can understand the way access works better. Thanks.
Does your report have a field called Review? If not, you either need to change the recordsource of the report so it is joined with the table that has review, or change your filter so it refers to the field that the report has.
Here's what I've done:
I created a Parameter Query in which one of the crtiterias is Between [Start Date] and [End Date]. I then put that Parameter Query along with other bound fields and created a subform. So far, no problems and it works great.
But I'm having issues when it comes to printing or trying to convert the form into a PDF. As soon as I ask it to print, for example, the pop-ups from the parameter query will pop up asking me the dates again and even after I enter them in (again), it keeps asking me multiple times and cancels the print job.
How do I keep the query from essentially running when I'm trying to print what's on the screen? The same thing happens if I'm trying to create a PDF.
In my not so humble opinion, parameters are handled badly in MS Access.
I think having to enter the values in the query whenever it is run (unless it is a one off experimental query) is just wrong headed. It would be so much easier to automate reports like that if you could just pass the parameters.
Typically, I create a report without the parameters in the where clause of the query, and then pass in your own where condition which gets added on Remou's answer here
You could also alter the query in the report before you call it, but that's pretty hackey.
-- Edit --
I see the confusion. I interpreted what you were doing as a report (not a form).
What's likely happening is you that when it tries to render/format the print job, it's having to make multiple calls to form's record source. And that why it keeps asking you for that data.
From what I understand in your question, you have a query that looks like this:
select foo
from bar
where
yaddah_date between [Start Date] and [End Date]
And then you've used that query as the record source for a form that you are trying to latter print as a PDF. First of all you should probably create a report that is an analogue of the form. And then open the report for printing with a filter on it:
DoCmd.OpenReport "myReport", , , , _
"yaddah_date between " & txtStartDate & _
" and " & txtEndDate
(the last part is basically the filter/where clause that report will apply to the results of the query that's generating its data).
If you MUST print the form, you can do something similar
DoCmd.OpenForm "foo", acNormal, , _
"yaddah_date between " & txtStartDate & _
" and " & txtEndDate
Or you can set the filter property of the form/subform.
I would like to know if there is a way to set the parameters in an Access 2007 query using VBA. I am new to using VBA in Access, and I have been tasked with adding a little piece of functionality to an existing app.
The issue I am having is that the same report can be called in two different places in the application. The first being on a command button on a data entry form, the other from a switchboard button. The report itself is based on a parameter query that has requires the user to enter a Supplier ID.
The user would like to not have to enter the Supplier ID on the data entry form (since the form displays the Supplier ID already), but from the switchboard, they would like to be prompted to enter a Supplier ID.
Where I am stuck is how to call the report's query (in the report's open event) and pass the SupplierID from the form as the parameter. I have been trying for a while, and I can't get anything to work correctly. Here is my code so far, but I am obviously stumped.
Private Sub Report_Open(Cancel As Integer)
Dim intSupplierCode As Integer
'Check to see if the data entry form is open
If CurrentProject.AllForms("frmExample").IsLoaded = True Then
'Retrieve the SupplierID from the data entry form
intSupplierCode = Forms![frmExample]![SupplierID]
'Call the parameter query passing the SupplierID????
DoCmd.OpenQuery "qryParams"
Else
'Execute the parameter query as normal
DoCmd.OpenQuery "qryParams"?????
End If
End Sub
I've tried Me.SupplierID = intSupplierCode, and although it compiles, it bombs when I run it. And here is my SQL code for the parameter query:
PARAMETERS [Enter Supplier] Long;
SELECT Suppliers.SupplierID, Suppliers.CompanyName, Suppliers.ContactName, Suppliers.ContactTitle
FROM Suppliers
WHERE (((Suppliers.SupplierID)=[Enter Supplier]));
I know there are ways around this problem (and probably an easy way as well) but like I said, my lack of experience using Access and VBA makes things difficult. If any of you could help, that would be great!
The suggestion being made here is to 100% REMOVE the parameter from the query. This not only solves your problem, but then means you can use the query for code, other forms and not have your whole design fall apart because one stupid form is not open (hence the VERY reason for your question).
So, remove the parameters from the query. This also means that your report will now not need some form that already opened. And again, if some silly form is not opened, why should your report fail to work?
So, remove the parameter. Now, in your form that opens the report, it can pass the filter, and more in point use what is a called a "where" clause. This "where" clause is designed in MS-access to solve the problem of having to know ahead of time what kind of parameters and filters you need. It occurs at runtime, and thus MANY DIFFERENT forms can call and open that report.
Now in the form that calls and opens the form, you go:
Docmd.OpenReport "rptSuppliers",acViewPreview, , _
"SupplierCode = " & me.SupplierCode
So, in the above, the parameter is created on the fly. The great advantage is tomorrow you can have another form open the same report and perhaps filter by region.
In the case of NO where clause being passed and a user simply opening the form, then no filters will be used and no prompts will occur and all records will show. This is probably your best approach.
However if for some strange reason you still deem it REALLY necessary to have some report prompt when one silly form just happens to not be opened, then place the following code in the forms on-open event.
If CurrentProject.AllForms("form1").IsLoaded = False Then
Me.Filter = "SupplierID = " & InputBox("Enter Supplier ID")
Me.FilterOn = True
End
However, I would really make efforts to avoid hard coding some silly form name in the reports open event. Not only does this mean your hard coding dependencies of some silly form that is now attached to a report, but if you later on copy that report, or even copy the original form (or even rename any of these objects), then you have to go into the application and hunt about and now find the places you as a developer introduced dependences. This approach can substantially increase the maintenance costs of an application and thus should be advoied.
So, the suggestion here is to dump the parameter query. Simply provide a form or some prompt system to launch the reports. Those forms should prompt the user for the information you wish to filter. Or as in your case the bound form and it current record provides that information. The beauty of this system is now there is no depdancy from the report.
Any form, or even any code down the road is free to pass a pramaeter, and it will not be limited to SupplierID, but can be any type of filter or parameter you wish.
Keep in mind that perhaps the user might not want that form to be open and perhaps they don't want the prompt. With your design and question the user will be forced to enter a parameter value even when launching the report without any forms open and not desiring to be prompted to allow them to view all reocrds in that report.
As I outlined in a recent post, I tend never to hardwire any parameters or form control references into the recordsources of reports or forms. Instead, I set them at runtime. The simplest way is by passing the WhereCondition property in the DoCmd.OpenForm/DoCmd.OpenReport:
DoCmd.OpenReport "MyReport", , , "[SupplierID]=" & Me!SupplierID
That assumes you're running it from a form that has the relevant SupplierID already present in its recordsource (i.e., you're on a record with that SupplierID).
More complicated is to use the OnOpen event of the report to set the reports's recordsource. That's what I outlined in the cited post above. But that example hardwires the choice to a selection form, whereas you might want to instead offer different sets of choices depending on context. There are two ways to handle that:
if A2003 and later, pass an OpenArg (the last parameter of the DoCmd.OpenReport) to tell the OnOpen event what to do to collect the information on what to filter to.
use an outside structure like a standalone class module to store criteria that the OnOpen event will read and act upon accordingly.
I suspect that the WhereCondition in the DoCmd.OpenReport is your easiest solution, but if you want details on the other two, just ask.