Parameter queries that ask a question each time in Base

Many queries differ only by one value. Members in Leeds, members in York, members in Hull. Orders in January, orders in February. Saving a separate query for each soon fills the navigation pane with near copies. A parameter query in Base by Zaweba replaces all of them with one: instead of typing a fixed value as the condition, you type a question in square brackets, and Base asks it every time the query runs.

Write [Which town?] as the condition on the town field and you have a query that works for any town.

Setting one up

In the query designer, go to the field you want to filter and type the prompt as its condition, in square brackets. The words inside the brackets are what people see when they are asked, so phrase them as a clear question. [Which town?] or [Orders from which date?] tells the person exactly what to type.

You can use more than one parameter in the same query. Two dates, one for the start and one for the end, make a date range that someone fills in each time, which is the classic use.

What happens when it runs

When you run the query, Base shows a dialog with each prompt. The dialog remembers the last answers, so if you ran it for Leeds yesterday, Leeds is already filled in today. That makes repeat runs quick and means a typo is easy to correct on the next go.

It isn't only the query itself that asks. Reports built on a parameter query ask too, so one report design prints for any town or any month. CSV export asks, so you can export just one slice of data. Buttons that open the query or print its report ask as well. Everything downstream of the query inherits the question.

On the exported website

When you export the database as a website, a parameter query becomes a page with a small form at the top. People type the values and see the results, and where the parameter is a date, the form shows a date box. That gives browser users the same flexible query you use on your PC, without them needing to know anything about how it is built.

Good uses

Date ranges for monthly and quarterly figures. A customer or supplier name for a statement. A town, region or category for a list. A minimum amount for a "large orders" check. In each case the design stays the same and only the value changes, so it makes sense to ask for it.

Pair a parameter query with a switchboard button and you have something close to a small application: click Monthly sales, type the month, see the report.

Prompts that people understand

Keep prompts specific. "Enter value" leaves people guessing; "Start date (dd/mm/yyyy)" tells them what is wanted and in what form, which matters since Base uses UK dates. If the field is text, think about whether people will type the value exactly as stored.

Don't turn every query into a parameter query. If a report is always run for the same thing, a fixed condition is quicker for whoever runs it, and there's no prompt to answer every time.