Parameter query

Ok Nikos,

It's over my head. So basically what I'd like is to have only one basic
form, and be able to hit different queries on it. Like one query is sorted
by owner then storenumber. Another query is sorted by storenumber, another
query is sorted by storename.

Then I'd like to be able to hit reports from it as well, based on whatever
query/filter is currently active. Hope this makes sense...Hope even more
that it's possible.

Let me know, I'm willing to do as much as I can, but like I said, this is
beyond my meager capabilities.

Thanks!

Darhl


"Nikos Yannacopoulos" wrote in message
...
Welcome!

Darhl Thomason wrote:
Very cool! It disables the button when there aren't any filters
applied...which I'm relatively sure you knew ;-)

Thanks tons!

d


"Nikos Yannacopoulos" wrote in message
...

Dahrl,

Just for the fun of it:

Add this just before the End Sub in the cboOwner_Change sub:

Me.Command55.Enabled = (Me.cboOwner "")

and this again at the end of the Command55_Click sub:

Me.Command55.Enabled = False

where Command55 is the new command button in my example, change to the
actual button name. Then, in the form's design, change the command
button's Enabled property (tab Data) to No. See what happens.

Nikos

Darhl Thomason wrote:

Wow Nikos,

That's cool! I really like putting the drop down into the header of the
form. I think I can use something similar to get rid of all my other
forms,
since they're all the same anyway, just based on different queries.

What I'd like to be able to do is remove the filter. I've been playing
with
a command button, but can't get that figured out either.

Thanks again for all your help!!!

Darhl


"Nikos Yannacopoulos" wrote in message
.. .


Darhl,

Glad you worked it out, it's much better this way, for your skills as
well
as your confidence!

By the way, since you have - correctly - joined the two tables on the
key
field, you could just add it to the query and filter on that one,
leaving
your combo as it was originally (bound column = 1). See change in
returned
database.

Another approach you could take is to put the combo on the same form
(header section) instead of using a separate one, make the form's
recordsource unfiltered (so it returns all records when opened), and
use
the combo's On Change event to apply a filter whenever changed,
dynamically, without having to move back and forth between forms. See
the
new form (and unfiltered query) I added in the returned database.

HTH,
Nikos

Darhl Thomason wrote:


You know what? I just reread your post, and it clued me in to what I
was
doing wrong. I had the bound column the 1st column which was the
owner
ID, not the owner name. When I changed the bound column to 2 (the
owner
name) then the query/report started working!

Thanks Van! Your suggestion was perfect.

Nikos, no need to tear through my database...unless you want to anyway
and can see some way to improve it.

Thanks guys! I've got more questions as I learn Access.

Darhl


"Darhl Thomason" wrote in message
.. .



Thanks for your help Van! It's appreciated.

d


"Van T. Dinh" wrote in
message
. ..



I leave this to Nikos aince I am sure he works it out in no time
when he
gets a copy of your database.

Van T. Dinh
MVP (Access)



"Darhl Thomason" wrote in message
...



Great question, I'll check that out this morning.

Thanks!

Darhl

So basically what I'd like is to have only one basic form, and be able to
hit different queries on it.
Now you're talking! That's the way to go.


Like one query is sorted by owner then storenumber. Another query is
sorted by storenumber, another query is sorted by storename.
Since the only thing that changes is the sort order, you can use one
form only, and change its recordsource at runtime through code. You
could use, say, a listbox or combo or option group on the form itself,
and change the recordsource dynamically, selecting a saved query. I
would take it one step further, though, and assign the recordset SQL in
the form's Open event through code (form's recordsource property in form
design left blank), and change it dynamically in the same manner,
getting rid of the saved queries altogether.

By the way, note that, although not necessarily applicable in this case,
loading a form's recordset through code can make a huge improvement in
the loading time in a split app over a network.


Then I'd like to be able to hit reports from it as well, based on whatever
query/filter is currently active. Hope this makes sense...Hope even more
that it's possible.
Makes perfect sense, and is absolutely feasible. The logic is exactly
the same: one report, load the recordsource on open (actually just
assign the form's recordsource as the report's recordsource in your
case), look at the selections on the form to apply the pertinent sorting
and filtering. Two buttons on the form, one to preview the report, one
to print it. Done deal.


HTH,
Nikos

Woo Hoo! This is awesome...thanks so much for your help!

So I took what you showed me, and added a 2nd option group to select between
open stores and all stores. It works fine, it defaults to open stores, but
the option button isn't selected. On your option group the owner/store
number option is defaulted and is selected in the option group as default...

Thanks again!

d


"Nikos Yannacopoulos" wrote in message
...
So basically what I'd like is to have only one basic form, and be able to
hit different queries on it.
Now you're talking! That's the way to go.


Like one query is sorted by owner then storenumber. Another query is
sorted by storenumber, another query is sorted by storename.
Since the only thing that changes is the sort order, you can use one form
only, and change its recordsource at runtime through code. You could use,
say, a listbox or combo or option group on the form itself, and change the
recordsource dynamically, selecting a saved query. I would take it one
step further, though, and assign the recordset SQL in the form's Open
event through code (form's recordsource property in form design left
blank), and change it dynamically in the same manner, getting rid of the
saved queries altogether.

By the way, note that, although not necessarily applicable in this case,
loading a form's recordset through code can make a huge improvement in the
loading time in a split app over a network.


Then I'd like to be able to hit reports from it as well, based on
whatever query/filter is currently active. Hope this makes sense...Hope
even more that it's possible.
Makes perfect sense, and is absolutely feasible. The logic is exactly the
same: one report, load the recordsource on open (actually just assign the
form's recordsource as the report's recordsource in your case), look at
the selections on the form to apply the pertinent sorting and filtering.
Two buttons on the form, one to preview the report, one to print it. Done
deal.


HTH,
Nikos

Boy, if I'm not careful I may actually learn something. I figured it out.
Now I need to figure out how to add an additional option in the selection.

d


"Darhl Thomason" wrote in message
...
Woo Hoo! This is awesome...thanks so much for your help!

So I took what you showed me, and added a 2nd option group to select
between open stores and all stores. It works fine, it defaults to open
stores, but the option button isn't selected. On your option group the
owner/store number option is defaulted and is selected in the option group
as default...

Thanks again!

d


"Nikos Yannacopoulos" wrote in message
...
So basically what I'd like is to have only one basic form, and be able
to
hit different queries on it.
Now you're talking! That's the way to go.


Like one query is sorted by owner then storenumber. Another query is
sorted by storenumber, another query is sorted by storename.
Since the only thing that changes is the sort order, you can use one form
only, and change its recordsource at runtime through code. You could use,
say, a listbox or combo or option group on the form itself, and change
the recordsource dynamically, selecting a saved query. I would take it
one step further, though, and assign the recordset SQL in the form's Open
event through code (form's recordsource property in form design left
blank), and change it dynamically in the same manner, getting rid of the
saved queries altogether.

By the way, note that, although not necessarily applicable in this case,
loading a form's recordset through code can make a huge improvement in
the loading time in a split app over a network.


Then I'd like to be able to hit reports from it as well, based on
whatever query/filter is currently active. Hope this makes sense...Hope
even more that it's possible.
Makes perfect sense, and is absolutely feasible. The logic is exactly the
same: one report, load the recordsource on open (actually just assign the
form's recordsource as the report's recordsource in your case), look at
the selections on the form to apply the pertinent sorting and filtering.
Two buttons on the form, one to preview the report, one to print it. Done
deal.


HTH,
Nikos

Dang...I got that figured out, too. Thanks a ton for all your help!

d
"Darhl Thomason" wrote in message
...
Boy, if I'm not careful I may actually learn something. I figured it out.
Now I need to figure out how to add an additional option in the selection.

d


"Darhl Thomason" wrote in message
...
Woo Hoo! This is awesome...thanks so much for your help!

So I took what you showed me, and added a 2nd option group to select
between open stores and all stores. It works fine, it defaults to open
stores, but the option button isn't selected. On your option group the
owner/store number option is defaulted and is selected in the option
group as default...

Thanks again!

d


"Nikos Yannacopoulos" wrote in message
...
So basically what I'd like is to have only one basic form, and be able
to
hit different queries on it.
Now you're talking! That's the way to go.


Like one query is sorted by owner then storenumber. Another query is
sorted by storenumber, another query is sorted by storename.
Since the only thing that changes is the sort order, you can use one
form only, and change its recordsource at runtime through code. You
could use, say, a listbox or combo or option group on the form itself,
and change the recordsource dynamically, selecting a saved query. I
would take it one step further, though, and assign the recordset SQL in
the form's Open event through code (form's recordsource property in form
design left blank), and change it dynamically in the same manner,
getting rid of the saved queries altogether.

By the way, note that, although not necessarily applicable in this case,
loading a form's recordset through code can make a huge improvement in
the loading time in a split app over a network.


Then I'd like to be able to hit reports from it as well, based on
whatever query/filter is currently active. Hope this makes
sense...Hope even more that it's possible.
Makes perfect sense, and is absolutely feasible. The logic is exactly
the same: one report, load the recordsource on open (actually just
assign the form's recordsource as the report's recordsource in your
case), look at the selections on the form to apply the pertinent sorting
and filtering. Two buttons on the form, one to preview the report, one
to print it. Done deal.


HTH,
Nikos