Set up a one-column named range for EACH of the criteria you want to filter on. Then use these as tables to filter your records in the WHERE clause. For instance, here’s an example that filters the text feild ‘GivenName’ and the numerical field ‘Number’ from a database called ‘data’.


SELECT distinct data.Number
, data.Gender
, data.Salary
, data.GivenName
, data.MiddleInitial
, data.Surname
, data.StreetAddress
, data.City
, data.State
, data.ZipCode
, data.Country
, data.Birthday
, data.BloodType
, data.Pounds

Number_min, Number_max, and GivenName_equals are the tables (i.e. named ranges) on the worksheet where you enter your desired criteria. You then refresh the query, and the recordset is updated accordingly. Unfortunately the query doesn’t refresh automatically when you amend your filter criteria, but I get around this by adding a ‘trigger’ parameter along the lines of AND data.GivenName [Trigger_parameter]. This parameter is then linked to a cell on the worksheet, and in that cell I have a formula that concatenates all the different filter data entry cells. Eg:
= Number_min & Number_max & GivenName_equals

So as soon as one of these criteria changes, the trigger parameter triggers the query to refresh.

Obviously you only want to have one Number_min and Number_max parameter, so the named range for these should only allow users to put in one parameter (i.e. one max and one min). But you can have as many GivenName parameters as you want.

You can also use wildcards in these. So %a% in the GivenName criteria table would return any names with an ‘a’ in them.

Note that one downside of this is you get some ‘memory leak’ if you use MS Query to query an open workbook…basically the query process uses some memory while it is running, and that memory then can’t be used by your computer until you exit Excel. But with the examples I’ve been playing with, I haven’t run out of memory.

At first glance it seems as though data type issues are the culprit in preventing the us from hitting SQL Server.

I know that CharIndex will accept char, nchar, varchar, nvarchar, text, and ntext strings, but for some reason, it won’t recognize the values fed from a parameter.

So then I tried passing the parameter through the Convert and Cast functions but apparently the SQL Server Driver complained that the parameter value can’t be derived when used as an argument in a function.

So the real issue seems to be that the SQL driver (and presumably the Oracle driver) can’t translate or interpret a parameter value when fed as an argument in a function. That is what I’m concluding anyway.

Nevertheless, Access doesn’t seem to have this problem.

And Colin has been right all along. This technique would seem to be severely limited to Access databases.