If all 18 controls on the form had the correct type of value present, there
would be only 9 ANDs on the SQL statement--well short of the 100
permitted--so it is theoretically possible to do what you asked.
In practice, though these controls could contain any kind of data if they
are unbound, or JET could misintrepret the values, especially if as the
parameters are undeclared. You can improve this situation by setting the
Format property of the unbound controls, and declaring the parameters so
they are typed (Parameters on the Query menu, in query design view.)
That still doesn't deal with what happens if any one of these controls does
not contain a value. At that point, the SQL statement will fall apart,
unless you add Nz() functions around each of the values to cope with Null,
but that introduces another range of problems.
The best solution is going to be to redesign this interface so that the
WHERE clause is built up dynamically from only those controls that actually
have a value. How you do that will depend on where this query is headed. If
it is for a report, you could leave all the criteria out of the query, and
use the WhereCondition for the OpenReport action. For an example, see the
2nd method in this article:
Limiting a Report to a Date Range
at:
http://allenbrowne.com/casu-08.html
If the form is to filter records for a form, you could build up a string in
exactly the same way, and apply it to the Filter property of your form
(rembering to set FilterOn as well.)
If the query really is needed to base another query on, you could even write
the SQL property of the QueryDef.
Sorry: that's not a simple answer. It wasn't really a simple question.