Using Tables as Parameters

[jgscott3]

I have a number of queries that require various parameters. However,
the parameters will change infrequently, so I do not want the user to
have to respond to them every time they run the queries. I am
tentatively setting up little tables to hold the parameters so they are
easily accessible to database administrators such as myself but will
not require user input every time the queries are run. My question is
whether this is the best way to accomplish my objectives?

Also, if this is a reasonable approach, I see no need to join the
"parameter tables" within the queries, as I can simply include them in
design view and incorporate the various parameters as constants.

Any thoughts on this approach or how to improve it would be
appreciated.

Thank you.

[Tom van Stiphout]

On 11 Dec 2006 13:15:32 -0800, "jg******@bellsouth.net"
<jg******@bellsouth.netwrote:

I don't get: "I do not want the user to have to respond to them every
time they run the queries". Are you saying: after they fill out the
parameters for the first time, next time the query should
automatically use the same parameters? Why would the user want the
same parameter values every time?

I'm assuming you're talking about parameter queries like:
select * from Customers where CustomerID = [Give Customer ID:]

Perhaps you have queries like:
Select * from WorkQueue where Department = [Give Department:]
and an individual user would always enter the same Department, but
another user would always enter a different value.
If you explain more, we'll be better able to help.

-Tom.

>I have a number of queries that require various parameters. However,
the parameters will change infrequently, so I do not want the user to
have to respond to them every time they run the queries. I am
tentatively setting up little tables to hold the parameters so they are
easily accessible to database administrators such as myself but will
not require user input every time the queries are run. My question is
whether this is the best way to accomplish my objectives?

Also, if this is a reasonable approach, I see no need to join the
"parameter tables" within the queries, as I can simply include them in
design view and incorporate the various parameters as constants.

Any thoughts on this approach or how to improve it would be
appreciated.

Thank you.

[Ron2006]

Without a clearer idea of what you are trying to do, here are some
possibilities:
1) Have the queries link to the control table field.
2) have the control table be part of the query but NOT linked but a
field from it used in the criteria for the other table. Have to have
ONLY have one record in that control table.
3) Have a form bound to the fields in that table and reference that
form/fields as criteria in query.
4) Using dlookup or some such load those fields into unbound (and
possibily even hidden) fields on a form and have the queries reference
those fields as criteria.

Ron

[jgscott3]

Ron2006 wrote:

Without a clearer idea of what you are trying to do, here are some
possibilities:
1) Have the queries link to the control table field.
2) have the control table be part of the query but NOT linked but a
field from it used in the criteria for the other table. Have to have
ONLY have one record in that control table.
3) Have a form bound to the fields in that table and reference that
form/fields as criteria in query.
4) Using dlookup or some such load those fields into unbound (and
possibily even hidden) fields on a form and have the queries reference
those fields as criteria.

Ron

Thanks, Ron.

2) is what I am currently doing. Having only 1 record in the control
table is not a problem.

I appreciate the other possibilities, especially 3). I have no
experience with forms (as my Access needs are almost entirely table
management and queries) but will look into them

John Scott