choose multiple items from list box - ms-access

Access 2007 How do I allow the user to pick multiple items from a dropdown or list box?
I can use either. Example, I add a list box to my form and make it bound to a field from the query the form was made from. Now the user needs to be able to pick 2-3 of the values in the list box.
I know that in the listbox properties (Multi Select) I can pick simple or Extended, but this does not save the choices.
Thanks

In the Access MDB database format, I don't believe it's possible to have a bound list box which is also multi-select. (Edit: Testing showed me it is possible to set the multi-select property ... but nothing gets stored in the bound field ... so it's not useful.) Which of multiple selected values should the db engine store?
Since you have Access 2007, you can use ACCDB format, and you might be able to have a multi-select list box if it's bound to a multi-value field. However, multi-value fields are too similar to lookup fields, and lookup fields are evil. (The Evils of Lookup Fields in Tables).
If it were me, I would choose a different approach for the user interface.

Related

Open the Edit List Items Window with a button in Access for ListBox Object

I have a List Box in my form.
I'm allowing the user to edit the contents which is a feature I'd like to have and the default feature works great for my needs. I know if you right click the list you get the Edit List Items Window too.
But my issue is most of my users are not Access savvy, so they may not know to right click to open the window. I'd like to make it so the blue edit button will open that window with VBA, but I can't figure out how to call opening that window with VBA.
Is this even possible, if so I'd love to know the call.
You can simulate the click on edit
Private Sub btnValueListEdit_Click()
Me.myListBox.SetFocus
DoCmd.RunCommand acCmdEditListItems
End Sub
But this is not recomended!
Have a look at Add items to a Value List from Allen Browne.
You can remove items that are actually being used in other records.
You can correct a misspelled item, but the records that already have the misspelled item are not corrected.
You can add items to your form, but in a split database, other users don't get these items. Consequently, other users add items with other names to their forms, even where they should be the same item.
If you answer No after using one of the new items, you now have items in the data that don't match the list.
If you answer Yes in an unsplit database, you introduce strange errors as multiple users attempt to modify objects that could be in use by other people.
If you answer Yes in an split database, the list of items in one front end no longer matches the lists in the others.
Your changes don't last anyway: they are lost when the front end is updated.
Conclusion
Use tables, not value lists, to manage lookup data. Create relationships with Relational Integrity.
Use these lookup tables (or queries based on them), as the RowSource for your combos. Do not use Value Lists for anything more than the simplest of choices that the user never needs to edit.
Use the Not In List event to add data to simple, single-field lookups such as types or categories.
If you only use Access 2007 or later, the List Items Edit Form property is a quick and easy way to nominate the form to use for managing the list items.
To edit the list in any version of Access, or to control how the editing works, use another event such as the combo's DblClick.

Dynamic Set of Fields in Access

I have tried several different ways of searching for this information with no luck so far...
Firstly, I am using Access 2013, and I wouldn't exactly call myself experienced with it...
I have a table with many fields and I want to be able to create a report dynamically that only uses a subset of those fields. The subset is to be determined by a ListBox (with multi select turned on) containing the list of all of the fields.
So, a user will:
Opens the filtering form that was created
Selects the fields they wish to view
Clicks "Generate Report"
The report will only shown the fields that were asked for
Is this possible? If so, how?

Access: Multi-value field

I am trying to design a form where the user can search records to filter a report. The user must be able to select many values from a particular field (multivalued field). I understand I can use a list box, but the field has a total of 3,000 records and cycling through is too much. I just want to know what other ways I can let the user insert multiple values?
I have these ideas, but maybe you guys have another better way:
Creating multiple combo boxes and keep them hidden until the user hits an “add” button, but this limits me to the amount of values I can have. If I have 10 hidden combo boxes I can only enter a total of 11 (10 hidden plus the original visible) values.
Is it possible to have a temporary data grid where the user just enters the values.
Then comes the problem of getting this into the SQL Record Source. I am thinking of the SQL IN clause.
Any help or ideas, will be greatly appreciated.
I think that you should create Comboboxes where values from next combo are dynamically populated when value in previous Combo has been changed so that way you can create hierarchy of values to select.
I've done something similar for a few different applications in slightly different ways. Basically, I present the user with a table, allow them to right-click > filter (the same could be accomplished by providing a filter textbox for each corresponding field in the table you want to allow filtering on... in your case it sounds like you only need one). The filter box allows them to use 'and' and 'or' along with the actual text of what they're looking for. Then they click a button that opens the report and fills the report's filter field with whatever filter they had applied.
Of course, this assumes the user is familiar with the data they're filtering, and requires a bit of training, but for me it was a simpler alternative than displaying a list with a bajillion entries in it. Your mileage of course may vary :)

MS-Access unbound ComboBox in DataSheet?

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.

checked list box

I am new to Access and i am in the process of creating a database for some of our users. I have designed a form where the user name, first and last name etc are inputted.
Some of these users work for more than one department which means I need some type of listbox control that allows them to select more than one department when they enter their contact info.
In VB Studios 2005, this control is called a CHECKED LISTBOX. I have looked everywhere in access but cant seem to find it or anything closely similar.
The option of a listbox or combobox is not feasible here as these only allow the user to select one option only when inputting their details. Any help with this is much appreciated.
Use an ordinary list box with the "Multi Select" property set to "Simple".
The user can then click multiple list items, all of which stay selected until they un-select them again.
You may wish to consider a subform, as this will save you the trouble of updating a table with the data from a list box. A subform can use a department-person junction table with person id as the linked child field and master field. A combobox bound to department id will allow the user to select departments.
If you are really set on having checkboxes, Stephen Lebans has a sample database that uses the built-in Access listbox with checkboxes (from one of the Access wizards).
There is another choice:
If you are using Access 2007, you can declare your field as a lookup field accepting multiple values.
When you bind the list box to that field, you will get checkboxes.
It's easy to use them.
You'll also find more information is available from the MS Office website.
However, note:
This is only possible in the new Access 2007 database format and you will not be able to save your database to the older MDB format.
Multiple value fields are not compatible with most other databases, meaning that if you decide one day to upsize to SQL Server, you'll have to redesign your tables to use a junction table as Remou mentioned.
These multi-value fields are difficult to use from VBA: the value they return is in fact another recordset that you must iterate through to get all the values.
Having said that, if you just want something simple and you're not planning on manipulating the database from code, then it can be a practical option, albeit not a very compatible or future-proof one.
I'm not using them, but I think others should be able make their own decision knowing what is available to them.