I have an access database with a form that contains two combo boxes. One combo box filters its options based on the selection of the first combo box. This works perfectly but - I have a command button that changes the record source of the form. I only know how to populate the combo boxes based on one table though. So when the form changes record sources the combo boxes are still filled with options from the first record source. How can I create a query that populates the combo box options not on one table in general but based on whatever the record source of the form is at the time?
In the same command button handler that changes the RecordSource, assign a new RowSource to each combo box. Better yet, do this in a separate sub that's called by the button handler. Your code will have to know, or be able to figure out, what the new RowSource should be to correspond to the new RecordSource.
Edit in reply to comments
The RowSource doesn't have to be a QueryDef object, it can just be an SQL statement:
Dim sSQL As String
sSQL = "select whatever from wherever"
comboBox.RowSource = sSQL
I can't see the comments at the same time I'm editing, but I didn't understand what you were asking in the second.... On a second, separate, look at the comments, I think you're asking it you can set the RowSource to the form's RecordSource property. This strikes me as a bad idea--you've probably got many more columns in the RecordSource than you'll want to deal with in the RowSource, and a basic principle of query construction is to only request the columns you want.
Related
I have simple table subform with 2 pulldown comboboxes. The challenge I'm having is that even though I've carefully mapped parameters to the subform's query driven table will NOT populate with data. I have made sure to have the "me.requery" event (after update) for each combobox pulldown.
Combobox 1 = [cmb_opt_verified]
Combobox 2 = [cmb_srv_capture_status]
The comboboxes are within a subform, that is embedded in to tab control, that is embedded into the parent Form
Where
Is the parent form
Is the subform
Is combobox 1
Is combobox 2
Is a table that is powered by a query with the combobox parameters mapped to it.
The table query has the subforms combo-box parameters mapped with respect to the subform's table. The expected result is a list from the application of combobox 1 AND combobox 2 user selection.
[Forms]![Server Data Workbench]![srv_AML_detail].[Form]![cmb_opt_verified]
[Forms]![Server Data Workbench]![srv_AML_detail].[Form]![cmb_srv_capture_status]
I've tried leaving the form running and switching between pulldown options, but not luck. The query is not updating at all even with refreshes. I am able to see the list if I hard code into the query either options from combobox 1 and combobox 2
Is there a way I can determine if the values that are in the comboboxes are truly making it to the query? Or is there something I'm missing in the mapping of the comboboxes to the form and query?
Any help is greatly appreciated.
Embarrassing.. my combobox was bounded to the wrong column. I fixed it by writing in a msgbox [forms]![blah]... and it displayed the recordID and not the text itself. Problem resolved. It's strange how in some cases the bounded column is right while in other cases it's wrong. guess it's MSAccess way to keep you on your toes - or the product is very buggy.
I apologize for probably silly question, but I've already dont know which words to use for searching what i need. I have the good programming experience but am pretty new to Access.
I have a form with the controls, also it has a subform with read-only list of people contacts. This list is populated by a dynamic query from multiple tables, so i don't know in design-time the count and names of all fields. The user wants to be able to manually pick up several contacts from the list to send them a single e-mail.
I used to a table control allows user to select multiple records (usually with ctrl). But it turned out that in Access datasheet the continuous selection is only allowed.
Then I thought of adding editable checkbox column to a readonly table, where the user would be able to mark the desired rows. But I have not found a way how to do this in Access. It seems that the method Append in Fields collection is available only for tables and indexes, but not for queries or recordsets.
I have also read advice to get rid of the subform, and display data in listbox with property multiselect = extended. But in this case, the user will lose the benefits of the table: he can't move and resize columns, sort and filter data.
I have a feeling that the decision should be very simple, I just do not know the conventional way of how to implement this functionality in Access. Help me please.
This is doable by utilizing the RecordsetClone property of the sub form. Here is an example:
Sub GetSelectedValue()
Dim rs as Recordset
Dim sContact as String
Set rs = Me.[SubFormName Goes Here].Form.RecordsetClone
rs.MoveFirst
rs.Move Me.[SubFormName Goes Here].Form.SelTop - 1
sContact = rs![Recordset Column Name Goes Here]
Set rs = Nothing
End Sub
You can put this on the main form via a button control that takes the active row contact and places that name into a listbox on your main form. Once the user has made all their choices, you can then run your e-mail program off the names within the listbox.
If you want a datasheet (for filter, sort, resize), then an editable checkbox is really your only option.
The column can be part of the original table, or create a join table with ID and check column, where you add the IDs from all records of your base table.
In the subform you can set all controls except the checkbox to Locked = True.
I have a form with a subform, and I want the subform record source that populates the subform to change depending on the inputs on some combo boxes in the main form.
Using VBA, I have built a function that generates the SQL statement I want to populate the subform with. I know this works because I have tested it with the msgbox and it gives me the SQL statement I want. The sql statement uses an aggregate function so the resulting table has a different structure than the table it is querying from.
The code I use to change the subform record source is:
me![subformname subform].form.recordsource=myfunction()
This has worked for me in the past, but does not work here, I simply get "#Name?" in the subform on my form.
When I open the subform separately I get "#Name?" but when I open the Recourd Source and run the query from the record source I get a value so I am confused.
Any ideas?
Try setting up two subforms - one for each format that you need - and when you swap the underlying recordsets also swap or hide/unhide the relevant subform. Then you can set the controlsource for the relevant controls to the fields that are actually available in the current recordset.
I got it to work by changing the structure of the subform I was changing so that the structure stayed the same when I altered the recordsource. The lesson is, you can change the recordsource in VBA, but you can't change the structure of the subform.
My problem occurred because I used an alias in my subform record source SELECT query. When I replaced the alias table names with the actual database table names in my VBA code, the .recordsource = strSQL01 statement worked and the data appeared in my subform.
I have a list box on an MS Access 2010 form that has its contents generated by a query. The list box lists new customer names; these names are the ones that are not listed in the Customers table in the DB.
The user can select a customer name on the list box and click a button to add that customer name to the Customers table.
Now, after the new customer is added to the Customers table, I want to refresh the table, i.e. I want to re-run the query that generates its contents. Is there a way to do this in VBA or by setting a property?
Thanks! :)
Listboxes, comboboxes, and forms/subforms have a Requery method that should refresh/requery/reload the underlying recordset.
Me.Requery 'Requery Form
Me.Listbox1.Requery 'Requery Listbox
Me.ComboBox1.Requery 'Requery ComboBox
Me.SubformControlName.Form.Requery 'Requery a subform
Choose the correct one above and change it to match the name of your control. I think you should put it at the end of your code on your button_click() procedure. In some scenarios you will place this code on a control's AfterUpdate event.
In ms-access 2007, i'm trying to make a form for a table. this table has foreign keys from 2 parent tables. so i thought i would make these fields a lookup. but i couldn't create a single lookup for each parent table because they are composite keys.
I decided to create a query in which for each of these parent tables and the child table with an extra field for each composite key. this works fine with a normal form using an unbound ComboBox... but the unbound ComboBox does not work in a DataSheet Subform. when i make changes to a ComboBox in the Subform code, they are applied to all the other ComboBoxes in the same column as well.
My questions:
is there a way to change the values of the individual unbound ComboBox?
is there a different control i should be using other than the ComboBox or the DataSheet Subform?
what is the normal work around for this situation?
I cannot bind the ComboBox's because the field from the query is calculated/an-expression as I said.
I ran across a form of this problem myself, so for the sake of posterity:
While generally, the advice "Don't use continuous forms/datasheets in this situtation" is the best advice...It is possible to work around this.
However, access will not let you update the value of a single control on a datasheet. What can be used instead in this case is a temporary table, which can, when used as a recordsource, become the values of those controls. You will need to repopulate the table, and requery the controls (requerying the entire form should work as well) every time the calculation needs to change, however. Furthermore, should you enable editing on the controls, you will have to write some VBA on each control to handle the update event (Before Update), and run your own query to update the source tables, not merely the temporary table. Annoying to do perhaps, but effective.
There is another possibillity, which may also work, but I haven't tried to do something quite like this myself. The rowsource of a combobox can be very complex, so it is probable that you do not need to update the comboboxes with VBA at all. The rowsource can depend on other controls (such as another combobox) using the syntax Me.Form!controlName or Forms!FormName!ControlName, which will allow you to form the composite key. Of course, you can also select from queries with a rowsource. What is more interesting is that queries can reference controls on your form, provided the form is open, and you should safely be able to modify that with VBA should you have to.
Between the two of these, you should be able to force access, kicking and screaming, to display any data you wish, even on a datasheet, and to allow the user to change that data (but only if you want it to), and using the BeforeUpdate event, drag modified data back to whatever table it came from.
Continuous forms and datasheets do not work well for editing in situations where combo boxes need to be changed conditionally. The problem is that if you use the OnCurrent event to set the Rowsource of the combo box, it will be OK for that row, but will then hide the stored values for other rows.
The solution is to never use continuous forms/datasheets for editing data when this is the case (I hardly ever use them for editing, in fact). You can create two subforms, a continuous/datasheet subform that functions as a list, and a detail subform, that displays one record. Make the list subform uneditable, and the detail subform editable. You can link the two of them by using the Link Child/Link Master property of the detail subform control, and set it to the PK of the list subform.
If your list subform is Me!List and your detail is Me!Form, and the PK field is MyID, your link properties for the detail subform would be:
Master: Me!List.Form!MyID
Child: MyID
When you move to a different record in the list form, it will be automatically loaded in the child form. Any edits to the previously displayed detail will be saved before record departure.