I have encountered issues with using "filtering menus" in report during development of database aplication for my employer.
For my filtering options I created buttons with OnClick Event:
DoCmd.GoToControl "MyReportField"
DoCmd.RunCommand acCmdFilterMenu
These buttons are embedded in subreport. Initial thought was to create buttons, similar to the one in ribbon, with filtering options (in final stages of development I am planning to disable/hide Access ribbon for users). I created 5 buttons, 3 for fields with data type Text, 1 with data type Date and 1 with Boolean data type.
To quote a classic, the buttons "are misbehaving." When I test their function in form in form view, the "BooleanFilterBtn" on click already doesn't display Yes/No options (or something similar), but displays 2 numeric values (like -24441 or -29696). And filter is not working whatsoever.
Another problem arises when I try to have active more than one filter at a time. Date field filter and one of the Text field filters are working when combined with another filter option. But after using one of the two remaining Text field filters, when I click any other of the filtering buttons, the FilterMenu becomes blank.
Worth noting is that right-clicking on given field in report works without issues, but not the way I want.
Given these rather odd behaviours I think I am missing something. Is there a way how to make FilterMenus work the way as familiar from the ribbon? If not, is there any other option with similar design, options that I could try out?
Additional info:
Subreport is connected with form through "MyIDField." Both subreport and form have query data source, already saved.
All field names and data types are matching.
EDIT: Also I should have written that the FilterBtns doesn't work if I open the subreport separately, they work only when I open form (with subreport in it), eventhough the FilterBtns are using only controls from the report.
EDIT2: Code behind filter button filtering Boolean data type (boolean data are in Report in form of Yes/No check-fields, as mentioned in June7 comment bellow):
Private Sub btn_FiltrGarant_Click()
DoCmd.GoToControl "Garant"
DoCmd.RunCommand acCmdFilterMenu
End Sub
When I change this code to:
Private Sub btn_FiltrGarant_Click()
Me.Garant.SetFocus
DoCmd.RunCommand acCmdFilterMenu
End Sub
Brings no effect, only that the loading time of actual FilterMenu takes a bit longer.
Example for Text data type field:
Private Sub btn_FiltrRzh_Click()
DoCmd.GoToControl "ZkracenyNazev"
DoCmd.RunCommand acCmdFilterMenu
End Sub
Changing code in the same manner:
Private Sub btn_FiltrRzh_Click()
Me.ZkracenyNazev.SetFocus
DoCmd.RunCommand acCmdFilterMenu
End Sub
Brings no effect too.
May it be that the FilterMenu is not meant to/available to be used in reports? Or may it be disabled in default settings of Access?
Because also the situation, that if I open the Report separately (not in form as a subreport, but just as report by itself in report view), using any of the FilterBtns gives me RunTime error 2046, that the action GoToControl is not available. Changing to SetFocus eliminates the error, but the button doesn't bring up any FilterMenu at all. But these issues are valid only if I open report separately (which is not my interest), but might be helpfull as information.
Right now, I don't know where the problem could be. Anything I could think of was data type/naming mismatch, but that's not the case.
FINAL EDIT: After almost a month (there were holydays) of trying and searching for a way how to make this setup work I decided to switch from subreport to subform, in which I will try to obtain the same functionality.
Maybe just reports are not supposed to be handled the way I wanted to.
Just out of courtesy I am putting June7 answer as verifiedfor the time spent on helping me.
Thank you.
Don't know why your yes/no field displays 2 numeric values like -24441 or -29696 in the filter menu. Regardless, not able to get the filter menu to act on a yes/no field at all. However, get around that with an expression in report RecordSource query that changes the Yes/No field from Boolean to text values and use the calculated field in report design, like:
SELECT *, IIf([fieldname], "Yes", "No") AS IsSomethingTrue FROM tablename;
Use Me.controlname.SetFocus instead of GoToControl so the report will open independently or as a sub object.
You have to be careful how you refer to a Report object that is within a subForm container. They do not behave the same as subforms in many ways.
Even a simple refresh is actually difficult to achieve, as reports are not meant to be dynamic like a form.
To refer to it in VBA you have to use the full form syntax;
[Forms]![MainFormName].[Form]![subReportHolderName].Requery
Using the normal Me.blah.blah reference will not work with a form embedded report. Note that you refer to the container - NOT the report object.
Related
Here's the crux of the question, I have 26 compliance queries to run, in a previous question it was suggested that I should filter a single query, or two, on a single report. I like this idea, and have rewritten the query to pull all available data from all the fields, this query works fine. The report will work fine as well, as it does with a model query that I had coded up beforehand. What I would like to do is this:
The end user is being given an interface in access that is locked down, I want them to click a button, and that button will run the query and send to the text box just the field that is called for.
I have tried doing this through VB using the where clause and aliasing the column being called, this did not work at all. I have the report currently pulling the correct data, but not displaying the dates along side it. But it is filtering correctly aside from that.
So what needs to happen is this : Button click : Query runs, and is filtered for "Compliance Issue 1" and puts the dates in "Compliance Issue 1" in the text box on the report.
Right now... I get a list of names, the correct list of names, but an empty column.
I have tried using OpenArgs, but all it did was fill in the date column with "Compliance Issue 1" not the actual data in that column.
Is what I am trying to do even possible in access, and if so does someone have a reference or suggested starting point.
My background : 6 Months of python coding, 3 months of SQL , and some limited access from 20 years ago.
As noted, using the filter of the openreport is without question the way to go (one would not write a whole bunch of different queries - you can send/have any filter for that report - you can EVEN use a sub query in the filter that you send to the report.
As for displaying values in the report that are not from "rows" of data?
There are two approaches that work quite well.
First up, is you have that launcher form. This of course allows the user to select critrea - maybe even some nice combob boxes. These selections take care and you build up the filter in code that you pass to the report.
As for text boxes to be filled out from that form and inclluded in the report?
If they are static values from the report (say filter options, or even just a notes box that you could type in some text? To display such values in textboxes on the report?
You can directly set the text box data source (in the designer) to the report propter form like this:
=(forms!MyPromptForm!notes)
So, any value you shove into text boxes on the report prompt form can thus be displayed in any text box on the report with the above type of expression. And it does not even take code to achieve this goal. So, you could say with above enter some notes into that text box, and thus on the report, whatever you typed into that text box will now show up in the report. You just drop in a text box onto the report, and set the data source of the text box to the above expression that references the form with the values we want from that form.
The next approach, and I often use this in the case that some value/expression/calculation has to occur for each row. In this case, you can use the reports on-detail format event. This allows you to run code for EACH row of data.
You are free to run ANY code in that event - and that includes after running such code to set a text box in the reports detail section.
So, say the query only had the Hotel ID (PK). This is a lame example, but you could then write this code in the on-format event of the reports detail section.
dim strSQL as string
dim rst as DAO.RecordSet
strSQL = "SELECT HotelName from tblHotels where ID = " & me.HotelID
set rst = CurrentDb.OpenRecordSet(strSQL)
me.HotelName = rst!HotelName
rst.Close
So in above, we assume that a row text box is called HotelID, and then in code we build a whole sql query from scratch, pulled the row data from a table, and then SHOVE/SET the value of the un-bound text box called hotelName.
As noted, the above is a simple example, but we are free to run any code we want, pull any data we want, and set the value of ANY text box for the given detail section ONE row of values.
So, above shows two approaches. The first approach is code free - and you can put forms! expression directly into the report, and the values from that report prompt form will thus show up directly in the report. However, if you need VBA code to run for each row, pull values, walk the dog, and THEN set a text box on that one details row of data, then you are as above shows free to write procedural code in the report that fires + runs for each row of data - and that means you can quite much do anything you want in terms of running code. I mean, even that on detail format event COULD pull values from your report prompt form, but as the 1st example shows, you can shove in forms! expression directly into a text box - and those forms! expressions can be values from a existing form that is open before the report is launched.
I am working on a complicated project in MS Access 2007.
I am having some difficulty finding the correct method/Syntax for having a query outside of the open form be requeried. I am still fairly new at the VBA so forgive me if I make mistake or I am incorrect.
I have created a query which uses the value of a particular Combo Box in my form as part of its WHERE criteria. I have tested that and it works just fine. Now I am working on an "After Update" event for the Combo Box in question so that When I change the value of that Combo Box in question it will automatically tell my query to rerun itself with the new value in the WHERE Clause.
I was originally thinking of using the following command in VBA
DoCmd.Requery [Queries]![TestQuery]
But I am unclear on if I can use the DoCmd.Requery since the query is outside of the open form and not imbedded into it.
I am looking for options on how best to accomplish this effect, Not Strictly VBA Only. So if a Macro would work better please give me an example to work from
UPDATE
Just to make things a little clearer Here is the actual SQL Code for the Select Query that I want to requery through this after Update event.
SELECT ForcastTrans.Location, ForcastTrans.Client, ForcastTrans.Department, ForcastTrans.Account, ForcastTrans.Currency, ForcastTrans.Month1, ForcastTrans.Month2, ForcastTrans.Month3, ForcastTrans.Month4, ForcastTrans.Month5, ForcastTrans.Month6, ForcastTrans.Month7, ForcastTrans.Month8, ForcastTrans.Month9, ForcastTrans.Month10, ForcastTrans.Month11, ForcastTrans.Month12
FROM ForcastTrans
WHERE (((ForcastTrans.EntityID)=[Forms]![ReportSelect]![BusinessUnit]));
As I said before this Query works just fine by itself I just need to be able to issue an after update event which will tell this query to Rerun based on the updated WHERE criteria.
Danke.
It still matters how you're building the report. I would assume that this query is the record source for the report and that the report is only generated when you request it from this very form you're updating. In which case, the query should automatically take the updated value when you load the report; If you're looking to generate the report after you close the form, then the query won't work once the combobox is destroyed. I'm still speculating on what exactly you want to do here, but suffice it to say, I don't recommend having a stored query that depends on an object in a form.
A cleaner way of doing this is to use a WhereCondition in your OpenReport call:
(inside a button click on ReportSelect)
DoCmd.OpenReport "YourReportName", acViewPreview,,"EntityID=" & Me.BusinessUnit
This opens your report filtered by the form that opens it, but still allows the report to open showing all of the data when the form is closed.
Kevin
been pulling my hair out with this one. Searched everywhere and can't get anythign to work. Here's my scenario:
I have a report with several subreports from linked tables. I would like to group the subreports to sort on a given field based on the value of a variable called SORT_BY, and force a page break for each value., i.e. Group a subreport on ItemDescription or ItemLocation. The SORT_BY variable is set from a users prefs dialog. (ya, I'm using it like a constant but the user can change it)
Now, I want the user to be able to preview the report before they print. I have the report being launched in ReportView mode. This allows me to place a "Print" button and a "Close" button in the header of the report (which do not print). I have it set this way because the user is locked out of the normal "ribbon" and other controls so I have to provide buttons. The buttons do not show up in PrintPreview mode.
Obviously, I need to accomplish this via VBA. I can't seem to get GroupLevel settings to work. I've tried a CreateGroupLevel function to no avail. Tried with existing groups and with no existing groups. I've tried abandoning the group idea and simply tried to Sort the subreports using the OrderBy property, and nothing works. I'm going crazy.
Does anyone have any suggestions... other than giving up? :-)
UPDATE:
I've been trying the CreateGrouplevel function before opening the main report. i.e. open each subreport in design view, add the group, close the subform, then open the main report. However, when I try to implement the CreateGroupLevel function, I get the error:
Run-time error '2154':
You can't call this function when the Group, Sort, and Total Pane is open.
I don't understand this. Here is my code:
DoCmd.OpenReport strReport, acViewDesign
intGroupLevel = CreateGroupLevel(strReport, "FluorescentDescription", True, False)
DoCmd.Close acReport, strReport
Thoughts?
OOOPS!
Ok, so I figured out te '2154' error. Silly really, if you have EVER turned on the Group, Sort, Total Pane while editing a report, it will automatically be turned on every time you enter Design View on that report until you physically turn it off. Strange. Still chipping away at this.
I sure someone will correct me if I am wrong, however I don't think putting the buttons on the report will work. Why not build your own custom toolbar to display that contains Print and Close
In the 'code behind' of the report is there anything I can do in code to query a property of the record source.
Sorry I'm new to access and VB, but I am wanting to achieve something along the lines of this
If Me.RecordSource["MYFieldName"] = "dan" Then
//do something
End If
Is this possible?
The only method for examining values in the recordset of a report is to have the field bound as the ControlSource of a control on the report. If it's a field that does not need to be printed on the report, then you have to add an invisible control. Deciding whether to place it in the form's header/footer or in the detail will depend on the layout of your report and what kind of data you're attempting to examine.
You used to be able to do this directly in A97 (without a hidden control), but the results were often confusing, as the data buffer behind the report is often one record ahead of what is displayed onscreen.
Also, you have to be careful which events you try to use, as the data in a report has a very different relationship to what is displayed than is the case in forms. That is, certain events cannot refer to data or controls because they happen at times where the controls do not really exist (or do not have any data in them).
In general, the only events I use in reports are OnOpen, OnNoData, OnClose and the Detail's OnFormat event, and I use them to set recordsource, controls sources, control width/visibility and to draw lines, and not much else.
EDIT: In another answer, #GuinnessFan points out something I didn't know, and that's that if you have a control on your report that is bound to the underlying field you want to refer to in code, you can do so. For instance, if you have a field called "Phone" in the underlying RecordSource and a control "txtPhone" bound to it, you can refer to Me!Phone directly in code.
My guess is that what's going on is that Access is setting up a VBA-usable wrapper only for the fields (i.e., the old hidden properties that are why you get compile-time checking of references like Me.Phone) that are used as ControlSources.
But it is still the case that to use the values from the underlying RecordSource in code, there has to be a control with that field as ControlSource, whether it's hidden or not. The new information is that you don't have to use the control name to get the value. This means it's possible to distinguish between the displayed value for a field and the value in the recordset behind the report, which are not always in alignment. I think that in general, in most situations you'll want to use the control value, as it's not clear whether the cursor of the underlying recordsource is on the same record as the one that's being displayed. Also, if you use page-level events for a report that displays more than one record on a page, it won't be obvious which record you'll be getting the data from.
If you want to do something every time the report comes across "dan"
Private Sub Detail_Format(Cancel As Integer, PrintCount As Integer)
If [MyFieldName] = "dan" Then
' do something here
End If
End Sub
For things like, "I want this field to have red text" you should look into Conditional Formating.
Used detail_format instead of print. [MyFieldName] instead of Me.MyFieldName
I have searched around, and it seems that this is a limitation in MS Access, so I'm wondering what creative solutions other have found to this puzzle.
If you have a continuous form and you want a field to be a combo box of options that are specific to that row, Access fails to deliver; the combo box row source is only queried once at the beginning of the form, and thus show the wrong options for the rest of the form.
The next step we all try, of course, is to use the onCurrent event to requery the combo box, which does in fact limit the options to the given row. However, at this point, Access goes nuts, and requeries all of the combo boxes, for every row, and the result is often that of disappearing and reappearing options in other rows, depending on whether they have chosen an option that is valid for the current record's row source.
The only solution I have found is to just list all options available, all the time. Any creative answers out there?
Edit Also, I should note that the reason for the combo box is to have a query as a lookup table, the real value needs to be hidden and stored, while the human readable version is displayed... multiple columns in the combo box row source. Thus, changing limit to list doesn't help, because id's that are not in the current row source query won't have a matching human readable part.
In this particular case, continuous forms make a lot of sense, so please don't tell me it's the wrong solution. I'm asking for any creative answers.
I also hate Access, but you must play with the cards you are dealt.
Continuous forms are a wonderful thing in Access, until you run into any sort of complexity as is commonly the case, like in this instance.
Here is what I would do when faced with this situation (and I have implemented similar workarounds before):
Place an UNBOUND combobox on the form. Then place a BOUND textBox for the field you want to edit.
Make sure the combobox is hidden behind (NOT invisible, just hidden) behind the textBox.
In the OnCurrent event fill the listBox with the necessary data. Go ahead and "Limit to list" it too.
In the OnEnter or OnClick event of the textBox give the combobox focus. This will bring the combobox to the forefront. When focus leaves the combobox it will hide itself once more.
In the AfterUpdate event of the combobox set the value of the textbox equal to the value of the combobox.
Depending on your situation there may be some other details to work out, but that should more or less accomplish your goal without adding too much complexity.
use continuous forms .. definitely. In fact you can build entire applications with great and intuitive user interface built on continuous forms. Don't listen to Toast!
Your solution of listing all options available is the correct one. In fact there is no other clean solution. But you are wrong when you say that Acccess goes nuts. On a continuous form, you could see each line as an instance of the detail section, where the combobox is a property common to all instances of the detail section. You can update this property for all instances, but cannot set it for one specific instance. This is why Access MUST display the same data in the combobox for all records!
If you need to accept only record-specific values in this combobox, please use the beforeUpdate event to add a control procedure. In case a new value cannot be accepted, you can cancel data update, bringing back the previous value in the field.
You cannot set the limitToList property to 'No' where the linked data (the one that is stored in the control) is hidden. This is logical: how can the machine accept the input of a new line of data when the linked field (not visible) stays empty?
You could also make the value of the combo box into an uneditable text field and then launch a pop-up/modal window to edit that value. However, if I was doing that, I might be inclined to edit the whole record in one of those windows.
I don't think that Access continuous forms should be condemned at all, but I definitely believe that they should be avoided for EDITING DATA. They work great for lists, and give you substantially more formatting capabilities than a mere listbox (and are much easier to work with, too, though they don't allow multi-select, of course).
If you want to use a continuous form for navigation to records for editing, use a subform displaying the detailed data for editing, and use the PK value from the subform for the link field. This can be done with a continuous form where you place a detail subform in the header or footer, linked on the PK of the table behind the continuous form.
Or, if you are using a continuous form to display child data in a parent form, you can link the detail subform with a reference to the PK in the continuous subform, something like:
[MySubForm].[Form]!MyID
That would be the link master property, and MyID would be the link child property.
We also encounter this a lot in our applicatins. What we have found to be a good solution:
Just show all rows in the comboboxes.
Then, as soon as the user enters the compobox in a specific row, adjust the rowsource (with the filter for that row). When the combobox loses the focus, you can re-set the rowsource to display everything.
I have a simpler way to go than Gilligan. It seems like a lot of work but it really isn't. My solution requires having my continuous form as a subform datasheet. On my subform I have two lookup comboboxes, among other fields, called Equipment and Manufacturer. Both simply hold a Long Integer key in the data source. Manufacturer needs to be filtered by what is selected in Equipment. The only time I filter Manufacturer.RowSource is in the Manufacturer_GotFocus event.
Private Sub Manufacturer_GotFocus()
If Nz(Me.Equipment, 0) > 0 Then
Me.Manufacturer.RowSource = GetMfrSQL() '- gets filtered query based on Equipment
Else
Me.Manufacturer.RowSource = "SELECT MfgrID, MfgrName FROM tblManufacturers ORDER BY MfgrName"
End If
End Sub
In Manufacturer_LostFocus I reset Manufacturer.RowSource to all Manufacturers as well. You need to do this because when you first click in the subform, GotFocus events fire for all controls, including Manufacturer, even though you are not actually updating any fields.
Private Sub Manufacturer_LostFocus()
Me.Manufacturer.RowSource = "SELECT MfgrID, MfgrName FROM tblManufacturers ORDER BY MfgrName"
End Sub
In the Enter event of Manufacturer you have to check if Equipment has been selected, if not set focus to Equipment.
Private Sub Manufacturer_Enter()
If Nz(Me.EquipmentID, 0) = 0 Then
'-- Must select Equipment first, before selecting Manufacturer
Me.Equipment.SetFocus
End If
End Sub
You also need to requery the Manufacturer combobox in Form_Current event (i.e. Me.Manufacturer.Requery), and you should set the Cycle property of this subform to "Current Record".
Seems simple enough, but you're not done yet. You also have to reset Manufacturer.RowSource to all Manufacturers in the SubForm_Exit event in the parent form in case the user goes to the Manufacturer combobox but does not make a selection and clicks somewhere on the parent form. Code sample (in parent form):
Private Sub sFrmEquip_Exit(Cancel As Integer)
Me.sFrmEquip.Controls("Manufacturer").RowSource = "SELECT MfgrID, MfgrName FROM tblManufacturers ORDER BY MfgrName"
End Sub
There is still one piece of this that is not clean. When you click on Manufacturer and have multiple rows in the datasheet grid, Manufacturer field will go blank in other rows (the data underneath the comboboxes is still intact) while you're changing the Manufacturer in the current row. Once you move off this field the text in the other Manufacturer fields will reappear.
This seems to work well.
CBOsfrmTouchpoint8 is a combobox shortened to just the dropdown square.
CBOsfrmTouchpoint14 is a textbox that makes up the rest of the space.
Never say never:
Private Sub CBOsfrmTouchpoint8_Enter()
If Me.CBOsfrmTouchpoint8.Tag = "Yes" Then
CBOsfrmTouchpoint14.SetFocus
Me.CBOsfrmTouchpoint8.Tag = "No"
Exit Sub
End If
Me.CBOsfrmTouchpoint8.Tag = "No"
Me.CBOsfrmTouchpoint8.RowSource = "XXX"
Me.CBOsfrmTouchpoint8.Requery
Me.CBOsfrmTouchpoint8.SetFocus
End Sub
Private Sub CBOsfrmTouchpoint8_GotFocus()
Me.CBOsfrmTouchpoint14.Width = 0
Me.CBOsfrmTouchpoint8.Width = 3420
Me.CBOsfrmTouchpoint8.Left = 8580
Me.CBOsfrmTouchpoint8.Dropdown
End Sub
Private Sub CBOsfrmTouchpoint8_LostFocus()
Me.CBOsfrmTouchpoint8.RowSource = "XXX"
Me.CBOsfrmTouchpoint8.Requery
End Sub
Private Sub CBOsfrmTouchpoint8_Exit(Cancel As Integer)
Me.CBOsfrmTouchpoint14.Width = 3180
Me.CBOsfrmTouchpoint8.Width = 240
Me.CBOsfrmTouchpoint8.Left = 11760
Me.CBOsfrmTouchpoint8.Tag = "Yes"
End Sub
What if you turn off the "Limit To List" option, and do some validation before update to confirm that what the user might have typed in matches something in the list that you presented them?
Better...
Set you combo box Control Source to a column on the query where the values from your combo box will be stored.
For Me I think the best way and easiest way is to create a temporary table that has all your bound fields plus an extra field that is a yeas/no field.
then you will use this table as the data source for the continuous for. You can use onLoad to fill the temporary table with the data you want.
I think it is easy after that to loop for the choices, just a small loop to read the yeas/no field form the temporary table.
I hope this will help
Use OnEnter event to populate the combo box, don't use a fixed rowsource.
I've just done similar. My solution was to use a fixed row source bound to a query. The query's WHERE clauses reference the form's control i.e. Client=Forms!frmMain!ClientTextBox. This alone will fill the combo boxes with the first row's data. The trick then is to set an 'On Enter' event which simply does a re-query on the combo box e.g. ComboBox1.Requery, this will re-query that combo box alone and will only drag in the data related to that record row.
Hope that works for you too!
Disclaimer: I hate Access with a passion.
Don't use continuous forms. They're a red herring for what you want to accomplish. Continuous forms is the same form repeated over and over with different data. It is already a kludge of Access's normal mode of operation as you can't have the same form opened multiple times. The behavior you are seeing is "as designed" in Access. Each of those ComboBox controls is actually the same control. You cannot affect one without affecting the others.
Basically, what you have done here is run into the area where Access is no longer suitable for your project (but cannot ditch because it represents a large amount of work already).
What seems to be the most likely course of action here is to fake it really well. Run a query against the data and then create the form elements programmatically based on the results. This is a fair amount of work as you will be duplicating a good bit of Access's data handling functionality yourself.
Reply to Edit:
But as they are, continuous forms cannot accomplish what you want. That's why I suggested faking out your own continuous forms, because continuous forms have real limitations in what they can do. Don't get so stuck on a particular implementation that you can't let go of it when it ceases to work.