Multi-Select criteria builder

I understand how to build and apply criteria from multi-select list boxes but what I am noticing is that multi-select list boxeas ... well ... are not user friendly if you have to scroll. It starts to feel bad when you have to scroll a lot so I have started thinking about using tables to collect the criteria so they can use a combobox to select each criteria.  I thought about this a little bit it on the ride in this morning but was wondering if anyone has used this approach and has any practical advice in implemeting this or reasons I should reconsider my approach.

LVL 39
Who is Participating?

Improve company productivity with a Business Account.Sign Up

Leigh PurvisConnect With a Mentor Database DeveloperCommented:
Hi Steve.
Good questions today - I'm indebted to you :-D

I've used table records for storing criteria before - though to be honest not recently.
(Not a conscious decision at all - just requirements based).
Indeed - have stored permanent parts of queries (Select/From/Group) and separately the selected criteria at runtime - pulling it all together at search/report time.

I think your concept is sound.
As long as you're displaying the criteria next to the selection methods (simply due to the add as you select concept - rather than select an entry and then click an "Add Criteria" button).
Should all work pretty effortlessly.
Of course you then have the age old decision to make.
Which optimizes better - a series of OR's or a couple of IN's  :-)
What do u mean by critera, do u mean data or list of fields?
stevbeAuthor Commented:
Sorry for not being clear, still working on second cup of coffee :-)
This is for user selecting report criteria ... select one or more customers, pick one or more vendors, one or more internal contacts etc.

so I was thinking if I had a seperate table for each type of multi-select criteria I could build a 1 column datasheet for and use them as subforms on my main report selector and criteria form, this way they can type/select from the combobox (auto complete and all :-)) and enter as many as they would like. I would then open a recordset and build the WhereCondition in the usual way for multi-select listbox

Select Vendor              Select Contact
----------------              --------------------
datasheet sub              datasheet sub
*     cbo                      *     cbo
----------------              --------------------
Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

rockiroadsConnect With a Mentor Commented:
Some of your combo values are probably dependant on other combo's?

Other thing is what if u users to select different vendors, I assume then u have some button somewhere that says "ADD THIS CRITERIA"

I would add in something like "All Vendors" or "All Contacts" (more user friendly than say leaving it blank) into your combos

Could the report u use, make use of a standard query which has joins/inner queries to this temp table? So u dont need a recordset? Im not too familiar with your setup. Actually thinking about it, it may be slow.

If not joins Im thinking take a preexisting query (using Querydefs) get the SQL and add your WHERE bits in (using the recordset as u say) Im assuming this is what u are doing.

I guess u have a number of different reports also

stevbeAuthor Commented:
<Some of your combo values are probably dependant on other combo's?>
no ... straight up ... no dependencies

<I assume then u have some button somewhere that says "ADD THIS CRITERIA">
no ... if they select something it is automatically included

<I would add in something like "All Vendors" or "All Contacts>
I will think about this ... they are use to the idea that selections restrict data but I understand the concept you are presenting and will give it another go around inside my head :-)

<make use of a standard query which has joins/inner queries to this temp table>
I was thinking not because there are actually 4 multi-select fields (which means I will have 4 criteria tables) they may or may not enter criteria in so I would need to have a version for each combination of joins or start writing the crazy Like "'*'" & Forms! ... "'*'" Like "'*'" nonsense that while I have gotten it correct in the past always takes me too long to get up to speed again when I go into maintenance mode :-)

<If not joins Im thinking take a preexisting query (using Querydefs) get the SQL and add your WHERE >
I typically leave the based SQL alone and pass the WHERE in the WhereCondition argument of DoCmd.OpenReport. just like I have in the past when using multi-select listboxes ... you know ... For Each varItem In lstVendor.ItemsSelected ...

<I guess u have a number of different reports also>
yes, I have a based query that includes all of the criteria fields and PK field and then for each report I build another query that joins my criteria query with the approriate table(s) to provide the rest of the field values for display on the report.

Thanks for the ideas, I really want to think about all aspects of rewriting my report criteria methodology before I spend the time. I am optimistic and may use this concept as a standard for all my apps as I try to reuse code, best practice UI, etc. for speeding development and consistency.

stevbeAuthor Commented:
I always go with IN's as this is for reporting and the perf should not be too different either way so they can wait :-) and  I don't have to worry about the number or ORs that Access can handle.
Leigh PurvisDatabase DeveloperCommented:
One beauty of a table based search is that it is then trivial to add "saved searches" - and to recall saved searches for use/editing :-)
stevbeAuthor Commented:
"saved searches"  =  v2.0

I am trying to figure out how *generic* I can make this process but I think I am always going to be stuck with modifing tbale names and delimiters per app.
Leigh PurvisDatabase DeveloperCommented:
Yeah I'd imagine you need to.
Some kind of search config table that determines the available options in any given application.
(Available searching fields and their types could be listed in such a table too - if you store the field type it saves hitting the db to determine them at runtime).

You'd just have to set up your search config table when you create each db.
(You'd not want every table to be searchable - as if nothing else - they'd be report dependent won't they?)
One question, since u say u add the selected criteria straight away

do u give the users the option to combine two combo boxes to make one filter for a report? or is it strictly one combo per table per report kinda thing

Im wondering if u allow multiple combination filters, how then do u handle that
Leigh PurvisDatabase DeveloperCommented:
Well - I was imagining either one combo for each field you want to filter on - and the relevant entries for each field (in lookup tables?) in each combo.
Select from a combo and an additional criteria added for that field with the selcted value...
One combo listing the fields - and a second one that adapts from the selection in the first to show appropriate lists.
Again - one click selection - critieria added based on field and value combos.

Naturally - the latter is more flexible with regards to the number of fields upon which you can limit the results (and hence port this from application to application).
stevbeAuthor Commented:
<I was imagining either one combo for each field you want to filter on>
maybe I did not explain my thoughts clearly ...

take the simple example of selecting multiple criteria for a single field. Normally I use a multi-select listbox but I am thining that I can use a 1 field datasheet subform that has 1 combobox for that field so instead of picking multiple items in the listbox they enter multiple records using their combobox ... I think I am going to give this a whirl, maybe I will make a sample and post it to EE-Stuff.
Leigh PurvisDatabase DeveloperCommented:
So how many fields do you search on?
You did have only one listbox?  And now only one combo - but instead of multi select - it's add to a table for each combo click.

Just on the one field?
stevbeAuthor Commented:
no ...current app is 4 multi-selects and 5 single selects, I have another we use here in IT that has 7 multis and 8 singles :-) Each multi and single is for a different field.
Leigh PurvisDatabase DeveloperCommented:
OK - so you'd then have 4 new combo's to replace each listbox?
So it's a multiple control search form - one per field?
stevbeAuthor Commented:
<OK> -- No, each listbox is replaced by a datatsheet form. Each datasheet form has 1 field and that field's control is a combobox.

<So> -- yes, but I am using a datasheet subform for each field instead of a multi-select listbox.

I should have a sample ready tomorrow so you can see how inept I am at explaining this :-)
Leigh PurvisDatabase DeveloperCommented:
Right - with you now.
(There must be a hundred ways of tackling this - hence the difficulty in seeing your particular vision).

I suppose UI requirements (screen real-estate) could determine different methods...

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.