By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,504 Members | 1,212 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,504 IT Pros & Developers. It's quick & easy.

Forcing a Form View

P: n/a
Hello everyone,

I'm new to access, so if this is a dumb question I apologize in
advance.

I created a query that requires a "parameter value" to be entered.
I then created a form to display the results of that query.

This worked fine and I am able to scroll throught the results of the
query in my form.

I then created a "command button" on the this form to call up the same
query as before.

The problem is that it displays the correct results, but only in
DATASHEET view.

How can I force it display the results in Form View.
(even a hammer won't work!)

Thanks,
Dave
Nov 13 '05 #1
Share this Question
Share on Google+
9 Replies


P: n/a
On Thu, 04 Aug 2005 13:08:34 GMT, David White wrote:
Hello everyone,

I'm new to access, so if this is a dumb question I apologize in
advance.

I created a query that requires a "parameter value" to be entered.
I then created a form to display the results of that query.

This worked fine and I am able to scroll throught the results of the
query in my form.

I then created a "command button" on the this form to call up the same
query as before.

The problem is that it displays the correct results, but only in
DATASHEET view.

How can I force it display the results in Form View.
(even a hammer won't work!)

Thanks,
Dave


Did you set the Default Form View property to either Continuous Form
or Single Form View?
It's on the Form's Property Sheet's Format tab.
What is the command button click event code?

The best way to do this, however, is to set the query as the form's
Record Source. Open the form and the query will prompt for the
parameter. Enter the parameter and the form will automatically display
the query result. There is no need for a separate command button.
--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.
Nov 13 '05 #2

P: n/a
On Thu, 04 Aug 2005 13:08:34 GMT, David White wrote:
Hello everyone,

I'm new to access, so if this is a dumb question I apologize in
advance.

I created a query that requires a "parameter value" to be entered.
I then created a form to display the results of that query.

This worked fine and I am able to scroll throught the results of the
query in my form.

I then created a "command button" on the this form to call up the same
query as before.

The problem is that it displays the correct results, but only in
DATASHEET view.

How can I force it display the results in Form View.
(even a hammer won't work!)

Thanks,
Dave


Did you set the Default Form View property to either Continuous Form
or Single Form View?
It's on the Form's Property Sheet's Format tab.
What is the command button click event code?

The best way to do this, however, is to set the query as the form's
Record Source. Open the form and the query will prompt for the
parameter. Enter the parameter and the form will automatically display
the query result. There is no need for a separate command button.
--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.
Nov 13 '05 #3

P: n/a
On Thu, 4 Aug 2005 06:56:37 -0700, fredg <fg******@example.invalid>
wrote:

I Like your idea about Opening the form and then receive a prompt for
the display.

The query is, however, the form's Record Source

Is the problem caused by the facr that I intially used the Form Wizard
to set up the form using the Query instead of the Underlying table?
Did you set the Default Form View property to either Continuous Form
or Single Form View?
It's on the Form's Property Sheet's Format tab.
What is the command button click event code?

The best way to do this, however, is to set the query as the form's
Record Source. Open the form and the query will prompt for the
parameter. Enter the parameter and the form will automatically display
the query result. There is no need for a separate command button.


Nov 13 '05 #4

P: n/a
On Thu, 4 Aug 2005 06:56:37 -0700, fredg <fg******@example.invalid>
wrote:

I Like your idea about Opening the form and then receive a prompt for
the display.

The query is, however, the form's Record Source

Is the problem caused by the facr that I intially used the Form Wizard
to set up the form using the Query instead of the Underlying table?
Did you set the Default Form View property to either Continuous Form
or Single Form View?
It's on the Form's Property Sheet's Format tab.
What is the command button click event code?

The best way to do this, however, is to set the query as the form's
Record Source. Open the form and the query will prompt for the
parameter. Enter the parameter and the form will automatically display
the query result. There is no need for a separate command button.


Nov 13 '05 #5

P: n/a
"David White" <dj*****@snet.net> wrote in message
news:te********************************@4ax.com...
Hello everyone,

I'm new to access, so if this is a dumb question I apologize in
advance.

I created a query that requires a "parameter value" to be entered.
I then created a form to display the results of that query.

This worked fine and I am able to scroll throught the results of the
query in my form.

I then created a "command button" on the this form to call up the same
query as before.

The problem is that it displays the correct results, but only in
DATASHEET view.

How can I force it display the results in Form View.
(even a hammer won't work!)

Thanks,
Dave

Dave,
It sounds like the problem is your command button. The "click" event is
likely set to open another query. Queries are always opened in datasheet
view. Try changing your "click" event to change the record source of the
form to the new query (instead of just opening the query).
Fred Zuckerman
Nov 13 '05 #6

P: n/a
"David White" <dj*****@snet.net> wrote in message
news:te********************************@4ax.com...
Hello everyone,

I'm new to access, so if this is a dumb question I apologize in
advance.

I created a query that requires a "parameter value" to be entered.
I then created a form to display the results of that query.

This worked fine and I am able to scroll throught the results of the
query in my form.

I then created a "command button" on the this form to call up the same
query as before.

The problem is that it displays the correct results, but only in
DATASHEET view.

How can I force it display the results in Form View.
(even a hammer won't work!)

Thanks,
Dave

Dave,
It sounds like the problem is your command button. The "click" event is
likely set to open another query. Queries are always opened in datasheet
view. Try changing your "click" event to change the record source of the
form to the new query (instead of just opening the query).
Fred Zuckerman
Nov 13 '05 #7

P: n/a
On Thu, 04 Aug 2005 14:12:48 GMT, David White wrote:
On Thu, 4 Aug 2005 06:56:37 -0700, fredg <fg******@example.invalid>
wrote:

I Like your idea about Opening the form and then receive a prompt for
the display.

The query is, however, the form's Record Source

Is the problem caused by the facr that I intially used the Form Wizard
to set up the form using the Query instead of the Underlying table?
Did you set the Default Form View property to either Continuous Form
or Single Form View?
It's on the Form's Property Sheet's Format tab.
What is the command button click event code?

The best way to do this, however, is to set the query as the form's
Record Source. Open the form and the query will prompt for the
parameter. Enter the parameter and the form will automatically display
the query result. There is no need for a separate command button.


If the command button event code is something like:
DoCmd.OpenQuery "QueryName"
that will open the query as a query (in datasheet view).

I believe you are going about this incorrectly. If the Query is the
form's record source, that should be all you need to filter and show
the appropriate records after entering the parameter when prompted.

Why don't you use the built-in Filter-by-Selection or Filter-by-Form
tool buttons to filter within the filter?

No need for a command button.
--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.
Nov 13 '05 #8

P: n/a
On Thu, 04 Aug 2005 14:12:48 GMT, David White wrote:
On Thu, 4 Aug 2005 06:56:37 -0700, fredg <fg******@example.invalid>
wrote:

I Like your idea about Opening the form and then receive a prompt for
the display.

The query is, however, the form's Record Source

Is the problem caused by the facr that I intially used the Form Wizard
to set up the form using the Query instead of the Underlying table?
Did you set the Default Form View property to either Continuous Form
or Single Form View?
It's on the Form's Property Sheet's Format tab.
What is the command button click event code?

The best way to do this, however, is to set the query as the form's
Record Source. Open the form and the query will prompt for the
parameter. Enter the parameter and the form will automatically display
the query result. There is no need for a separate command button.


If the command button event code is something like:
DoCmd.OpenQuery "QueryName"
that will open the query as a query (in datasheet view).

I believe you are going about this incorrectly. If the Query is the
form's record source, that should be all you need to filter and show
the appropriate records after entering the parameter when prompted.

Why don't you use the built-in Filter-by-Selection or Filter-by-Form
tool buttons to filter within the filter?

No need for a command button.
--
Fred
Please only reply to this newsgroup.
I do not reply to personal email.
Nov 13 '05 #9

P: n/a
On Thu, 4 Aug 2005 09:16:44 -0700, fredg <fg******@example.invalid>
wrote:

Thank you both for your input.

I took your suggestion and created a filter by copying and pasting a
part of the Query in "SQL view" to the Form's Property-Filter Record.

I then created a Command button to apply the filter. Works great.

Thanks again,
Dave

Nov 13 '05 #10

This discussion thread is closed

Replies have been disabled for this discussion.