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

Change the recordset of an Access report on Open

P: n/a
When I open an Access form I can have no recordset specified, then in
the form's OnOpen event I can do something like:
Me.paramaters = "@SomeColumn = 22)"
Me.recordsource = "dbo.sproc123"

But I can't do this in a report as it will prompt me for the
parameters, even though they seem to be defined ahead of the
recordsource.

I have worked around this by opening reports to a bogus recordsource
that has the same underlying parameters and tables but is designed to
return only one record, then in the report's OnOpen event I specify the
recordsource I want.This seems like a waste of speed and bandwidth.

The reason I am doing this is because I have some forms with multiple
recordsources that share the same report and in the OnOpen of the
report I user something like:

me.recordsource = Forms!myForm.RecordSource
Am I missing something here?

Thanks,
lq

Nov 13 '05 #1
Share this Question
Share on Google+
8 Replies


P: n/a
lauren quantrell wrote:
When I open an Access form I can have no recordset specified, then in
the form's OnOpen event I can do something like:
Me.paramaters = "@SomeColumn = 22)"
Me.recordsource = "dbo.sproc123"

But I can't do this in a report as it will prompt me for the
parameters, even though they seem to be defined ahead of the
recordsource.

I have worked around this by opening reports to a bogus recordsource
that has the same underlying parameters and tables but is designed to
return only one record, then in the report's OnOpen event I specify the
recordsource I want.This seems like a waste of speed and bandwidth.

The reason I am doing this is because I have some forms with multiple
recordsources that share the same report and in the OnOpen of the
report I user something like:

me.recordsource = Forms!myForm.RecordSource
Am I missing something here?


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No. You're do it correctly. The recordset is not retrieved until after
the Report's Open event finishes. Therefore, all the code you run in
the Open event occurs before any data is retrieved, and, there isn't a
waste of speed & bandwidth.

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQjX7joechKqOuFEgEQL8oACgxuhV4ty3j5nqzrJegp2WOf p9HfEAoOLK
X7SwcK/5IG7VYrLbqFv3+pUq
=BIAT
-----END PGP SIGNATURE-----
Nov 13 '05 #2

P: n/a
And dare I ask you have tried this using an Access project with
parameters passed to the stored procedure recordsource?

lq

MGFoster wrote:
lauren quantrell wrote:
When I open an Access form I can have no recordset specified, then in the form's OnOpen event I can do something like:
Me.paramaters = "@SomeColumn = 22)"
Me.recordsource = "dbo.sproc123"

But I can't do this in a report as it will prompt me for the
parameters, even though they seem to be defined ahead of the
recordsource.

I have worked around this by opening reports to a bogus recordsource that has the same underlying parameters and tables but is designed to return only one record, then in the report's OnOpen event I specify the recordsource I want.This seems like a waste of speed and bandwidth.

The reason I am doing this is because I have some forms with multiple recordsources that share the same report and in the OnOpen of the
report I user something like:

me.recordsource = Forms!myForm.RecordSource
Am I missing something here?
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

No. You're do it correctly. The recordset is not retrieved until

after the Report's Open event finishes. Therefore, all the code you run in
the Open event occurs before any data is retrieved, and, there isn't a waste of speed & bandwidth.

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQjX7joechKqOuFEgEQL8oACgxuhV4ty3j5nqzrJegp2WOf p9HfEAoOLK
X7SwcK/5IG7VYrLbqFv3+pUq
=BIAT
-----END PGP SIGNATURE-----


Nov 13 '05 #3

P: n/a
lauren quantrell wrote:
And dare I ask you have tried this using an Access project with
parameters passed to the stored procedure recordsource?


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Yes, I did; and got an error. Found this KB article which explained how
to fix it:

http://support.microsoft.com/default...b;en-us;300693

--
MGFoster:::mgf00 <at> earthlink <decimal-point> net
Oakland, CA (USA)

-----BEGIN PGP SIGNATURE-----
Version: PGP for Personal Privacy 5.0
Charset: noconv

iQA/AwUBQjYaN4echKqOuFEgEQJ6igCgj8FBboSDICQxyIEldGmi8o WzK8gAoPFv
wztRIHYaDOKn9QLOanGHb/Ly
=vO2O
-----END PGP SIGNATURE-----
Nov 13 '05 #4

P: n/a
Lauren,

I have a fairly large ADP. In my experience you cannot change the report
recordsource or parameters in the code of the report. There are two ways to
accomplish a changing recordsource for a report.

1) Before running the report, your application can open it in design mode
(which can be hidden) and change the necessary setting, save it, close it
and reopen it. There are several negatives to this methodology. First,
your app MUST be and adp (not ade) and your users must have full Access
installed (Not runtime), as you are actually doing design changes, albiet
through code.

2) My preferred method is to base a report off of a stored procedure and
have the input parameters refer to a "Control" form that stores all of the
necessary info that the stored procedure needs to return a recordset to the
report. If you have very different data, you will most likely want to open
a different report based on an option on the "Control" form.

Using method two, you would set your report recordsouce in the properties
window to "dbo.SomeStoredProcedure". Then in the inputParameters you would
put something like:

@Param1 INT = Forms("ControlForm")("txtBoxWithInfo1"), @Param2 VARCHAR(20)
= Forms("ControlForm")("txtBoxWithInfo2")

HTH,
Jim
"lauren quantrell" <la*************@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
When I open an Access form I can have no recordset specified, then in
the form's OnOpen event I can do something like:
Me.paramaters = "@SomeColumn = 22)"
Me.recordsource = "dbo.sproc123"

But I can't do this in a report as it will prompt me for the
parameters, even though they seem to be defined ahead of the
recordsource.

I have worked around this by opening reports to a bogus recordsource
that has the same underlying parameters and tables but is designed to
return only one record, then in the report's OnOpen event I specify the
recordsource I want.This seems like a waste of speed and bandwidth.

The reason I am doing this is because I have some forms with multiple
recordsources that share the same report and in the OnOpen of the
report I user something like:

me.recordsource = Forms!myForm.RecordSource
Am I missing something here?

Thanks,
lq



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 13 '05 #5

P: n/a
Jim,
Thanks for your response.
I use your method of parameters in all of my reports. The problem is
the recordsource of the form changes among many stored procedures.
It's starting to look like I need to create many reports and open the
appropriate one based on the stored procedure of the form, rather than
the other way around of changing the stored procedure of the report...
Thanks,
lq
J. Clay wrote:
Lauren,

I have a fairly large ADP. In my experience you cannot change the report recordsource or parameters in the code of the report. There are two ways to accomplish a changing recordsource for a report.

1) Before running the report, your application can open it in design mode (which can be hidden) and change the necessary setting, save it, close it and reopen it. There are several negatives to this methodology. First, your app MUST be and adp (not ade) and your users must have full Access installed (Not runtime), as you are actually doing design changes, albiet through code.

2) My preferred method is to base a report off of a stored procedure and have the input parameters refer to a "Control" form that stores all of the necessary info that the stored procedure needs to return a recordset to the report. If you have very different data, you will most likely want to open a different report based on an option on the "Control" form.

Using method two, you would set your report recordsouce in the properties window to "dbo.SomeStoredProcedure". Then in the inputParameters you would put something like:

@Param1 INT = Forms("ControlForm")("txtBoxWithInfo1"), @Param2 VARCHAR(20) = Forms("ControlForm")("txtBoxWithInfo2")

HTH,
Jim
"lauren quantrell" <la*************@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
When I open an Access form I can have no recordset specified, then in the form's OnOpen event I can do something like:
Me.paramaters = "@SomeColumn = 22)"
Me.recordsource = "dbo.sproc123"

But I can't do this in a report as it will prompt me for the
parameters, even though they seem to be defined ahead of the
recordsource.

I have worked around this by opening reports to a bogus recordsource that has the same underlying parameters and tables but is designed to return only one record, then in the report's OnOpen event I specify the recordsource I want.This seems like a waste of speed and bandwidth.

The reason I am doing this is because I have some forms with multiple recordsources that share the same report and in the OnOpen of the
report I user something like:

me.recordsource = Forms!myForm.RecordSource
Am I missing something here?

Thanks,
lq

----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet

News==---- http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups ----= East and West-Coast Server Farms - Total Privacy via Encryption

=----

Nov 13 '05 #6

P: n/a
Thanks for your reply. I read the link but unfortunately that structure
in the Microsoft solution (strRecordSource = "Exec [Sales By Year]
'1/1/97','12/31/98'") isn't available to Access2K which my appliation
is.
lq

Nov 13 '05 #7

P: n/a
The other option is to create a "Master" stored procedure that is the record
source for the report. From within that SP, you can call the appropriate
stored procedure that you really want based on an input parameter. You
would just use a case statement within the master to call each of the "Sub"
procedures.

Jim

"lauren quantrell" <la*************@hotmail.com> wrote in message
news:11*********************@o13g2000cwo.googlegro ups.com...
Jim,
Thanks for your response.
I use your method of parameters in all of my reports. The problem is
the recordsource of the form changes among many stored procedures.
It's starting to look like I need to create many reports and open the
appropriate one based on the stored procedure of the form, rather than
the other way around of changing the stored procedure of the report...
Thanks,
lq
J. Clay wrote:
Lauren,

I have a fairly large ADP. In my experience you cannot change the

report
recordsource or parameters in the code of the report. There are two

ways to
accomplish a changing recordsource for a report.

1) Before running the report, your application can open it in design

mode
(which can be hidden) and change the necessary setting, save it,

close it
and reopen it. There are several negatives to this methodology.

First,
your app MUST be and adp (not ade) and your users must have full

Access
installed (Not runtime), as you are actually doing design changes,

albiet
through code.

2) My preferred method is to base a report off of a stored procedure

and
have the input parameters refer to a "Control" form that stores all

of the
necessary info that the stored procedure needs to return a recordset

to the
report. If you have very different data, you will most likely want

to open
a different report based on an option on the "Control" form.

Using method two, you would set your report recordsouce in the

properties
window to "dbo.SomeStoredProcedure". Then in the inputParameters you

would
put something like:

@Param1 INT = Forms("ControlForm")("txtBoxWithInfo1"), @Param2

VARCHAR(20)
= Forms("ControlForm")("txtBoxWithInfo2")

HTH,
Jim
"lauren quantrell" <la*************@hotmail.com> wrote in message
news:11**********************@f14g2000cwb.googlegr oups.com...
When I open an Access form I can have no recordset specified, then in the form's OnOpen event I can do something like:
Me.paramaters = "@SomeColumn = 22)"
Me.recordsource = "dbo.sproc123"

But I can't do this in a report as it will prompt me for the
parameters, even though they seem to be defined ahead of the
recordsource.

I have worked around this by opening reports to a bogus recordsource that has the same underlying parameters and tables but is designed to return only one record, then in the report's OnOpen event I specify the recordsource I want.This seems like a waste of speed and bandwidth.

The reason I am doing this is because I have some forms with multiple recordsources that share the same report and in the OnOpen of the
report I user something like:

me.recordsource = Forms!myForm.RecordSource
Am I missing something here?

Thanks,
lq



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet

News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World!

120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption

=----



----== Posted via Newsfeeds.Com - Unlimited-Uncensored-Secure Usenet News==----
http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----
Nov 13 '05 #8

P: n/a
Jim,
Yours is the perfect solution. I will do just that whern I get the
time.
lq

Nov 13 '05 #9

This discussion thread is closed

Replies have been disabled for this discussion.