Caching results - can't stop it

When I run the web-based report viewer
(http://url/ReportServer?<parameters>), it is caching the results. I can go
to another part of my web app and change some data, but when I go back to
the report, it doesn't reflect changes. Also, if I change the report and
redeploy from Vis. Studio and hit the same URL for the report, I don't see
the changes. {That is, until I hit the little "refresh" button on the
report viewer toolbar. The cache does "time out" eventually, but I have not
tried measuring that time.}
I've set the web site properties on the ReportServer virtual to "Expire
Content Immediately." I've also checked the reports themselves and made
sure the Execution properties have selected "Render this report with the
most recent data" and "Do not cache temporary copies of this report" -- both
are true. So why aren't my updates reflected on the next page hit
automatically?What you are seeing is IE caching issue. That is why it works (and why they
have) the refresh button. When using the URL it is the same as the IE
refresh which causes the IE cache to be used. With your URL add this to the
report url: rs:ClearSession=true
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"DJM" <msnews@.puddlestheshark.com> wrote in message
news:%23Xg56aXNFHA.3296@.TK2MSFTNGP15.phx.gbl...
> When I run the web-based report viewer
> (http://url/ReportServer?<parameters>), it is caching the results. I can
go
> to another part of my web app and change some data, but when I go back to
> the report, it doesn't reflect changes. Also, if I change the report and
> redeploy from Vis. Studio and hit the same URL for the report, I don't see
> the changes. {That is, until I hit the little "refresh" button on the
> report viewer toolbar. The cache does "time out" eventually, but I have
not
> tried measuring that time.}
> I've set the web site properties on the ReportServer virtual to "Expire
> Content Immediately." I've also checked the reports themselves and made
> sure the Execution properties have selected "Render this report with the
> most recent data" and "Do not cache temporary copies of this report" --
both
> are true. So why aren't my updates reflected on the next page hit
> automatically?
>|||I added the rs:ClearSession parameter, but now it's kicking my users out of
the system (it's the only thing that changed, so this is definitely the
source of the problem -- the web app is under forms authentication) -- it
appears to be clearing out the whole session, not just anything related to
the Report Server. This is extremely bad.
"DJM" <msnews@.puddlestheshark.com> wrote in message
news:%23Xg56aXNFHA.3296@.TK2MSFTNGP15.phx.gbl...
> When I run the web-based report viewer
> (http://url/ReportServer?<parameters>), it is caching the results. I can
> go to another part of my web app and change some data, but when I go back
> to the report, it doesn't reflect changes. Also, if I change the report
> and redeploy from Vis. Studio and hit the same URL for the report, I don't
> see the changes. {That is, until I hit the little "refresh" button on the
> report viewer toolbar. The cache does "time out" eventually, but I have
> not tried measuring that time.}
> I've set the web site properties on the ReportServer virtual to "Expire
> Content Immediately." I've also checked the reports themselves and made
> sure the Execution properties have selected "Render this report with the
> most recent data" and "Do not cache temporary copies of this report" --
> both are true. So why aren't my updates reflected on the next page hit
> automatically?
>|||Ahh, didn't know you were doing forms authentication.
If the issue is only when you roll out a change then what you need to do is
when you roll out a change the user might need to close IE and then re-open
it.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"DJM" <msnews@.puddlestheshark.com> wrote in message
news:OLCt4%23tNFHA.3704@.TK2MSFTNGP12.phx.gbl...
> I added the rs:ClearSession parameter, but now it's kicking my users out
of
> the system (it's the only thing that changed, so this is definitely the
> source of the problem -- the web app is under forms authentication) -- it
> appears to be clearing out the whole session, not just anything related to
> the Report Server. This is extremely bad.
> "DJM" <msnews@.puddlestheshark.com> wrote in message
> news:%23Xg56aXNFHA.3296@.TK2MSFTNGP15.phx.gbl...
> > When I run the web-based report viewer
> > (http://url/ReportServer?<parameters>), it is caching the results. I
can
> > go to another part of my web app and change some data, but when I go
back
> > to the report, it doesn't reflect changes. Also, if I change the report
> > and redeploy from Vis. Studio and hit the same URL for the report, I
don't
> > see the changes. {That is, until I hit the little "refresh" button on
the
> > report viewer toolbar. The cache does "time out" eventually, but I have
> > not tried measuring that time.}
> >
> > I've set the web site properties on the ReportServer virtual to "Expire
> > Content Immediately." I've also checked the reports themselves and made
> > sure the Execution properties have selected "Render this report with the
> > most recent data" and "Do not cache temporary copies of this report" --
> > both are true. So why aren't my updates reflected on the next page hit
> > automatically?
> >
>|||It's not; it's whenever a report is run.
A little more detail:
We have a web application, let's say it's at www.url.com, which is not the
same as the server's default web site. This site is secured using Forms
Authentication. We wanted to add the Report Viewer to our application.
What we did was to add the ReportServer virtual to the www.url.com website,
and add a page to our application with a ReportViewer control and direct it
to www.url.com/ReportServer. (We copied the ReportServer folder on the
server, so we could set its configuration independent of the
defaultip/ReportServer site.) Unfortunately, we had some difficulty getting
this virtual to work with Forms Auth -- we tried the sample Forms Auth
validator, we tried just setting it to Forms Auth (hoping it would inherit
the authentication from the parent site -- it didn't, it just kept
redirecting its frame to our login page), and ultimately, we ended up just
turning authentication off completely. (Yes, this is absolutely insecure,
but we were unfortunately under "just make it work" pressure, and it was the
only way we could get the stupid login box to go away whenever a user tried
to run a report.)
When adding the rs:ClearSession to the querystring, it appears to annihilate
the Session of our web app -- the error we're seeing is actually a page that
is displayed when our web app detects the Session object is no more (which
usually only happens on a Session Timeout). As soon as we removed that
parameter (fortunately we store this in Web.config), our apparent timeout
problems went away immediately.
But we're back at this same problem where a user can run a report, go to
another part of the app and change data, come back to this same report, and
not see the updates immediately, despite the fact that all reports are set
to "render with most recent data" and "do not cache" and the
www.url.com/ReportServer virtual is set in IIS to "expire content
immediately".
"Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
news:OIIcIpuNFHA.576@.TK2MSFTNGP15.phx.gbl...
> Ahh, didn't know you were doing forms authentication.
> If the issue is only when you roll out a change then what you need to do
> is
> when you roll out a change the user might need to close IE and then
> re-open
> it.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "DJM" <msnews@.puddlestheshark.com> wrote in message
> news:OLCt4%23tNFHA.3704@.TK2MSFTNGP12.phx.gbl...
>> I added the rs:ClearSession parameter, but now it's kicking my users out
> of
>> the system (it's the only thing that changed, so this is definitely the
>> source of the problem -- the web app is under forms authentication) -- it
>> appears to be clearing out the whole session, not just anything related
>> to
>> the Report Server. This is extremely bad.
>> "DJM" <msnews@.puddlestheshark.com> wrote in message
>> news:%23Xg56aXNFHA.3296@.TK2MSFTNGP15.phx.gbl...
>> > When I run the web-based report viewer
>> > (http://url/ReportServer?<parameters>), it is caching the results. I
> can
>> > go to another part of my web app and change some data, but when I go
> back
>> > to the report, it doesn't reflect changes. Also, if I change the
>> > report
>> > and redeploy from Vis. Studio and hit the same URL for the report, I
> don't
>> > see the changes. {That is, until I hit the little "refresh" button on
> the
>> > report viewer toolbar. The cache does "time out" eventually, but I
>> > have
>> > not tried measuring that time.}
>> >
>> > I've set the web site properties on the ReportServer virtual to "Expire
>> > Content Immediately." I've also checked the reports themselves and
>> > made
>> > sure the Execution properties have selected "Render this report with
>> > the
>> > most recent data" and "Do not cache temporary copies of this report" --
>> > both are true. So why aren't my updates reflected on the next page hit
>> > automatically?
>> >
>>
>|||I have not done this so I am fresh out of ideas for you. Hopefully someone
else can jump in.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"DJM" <msnews@.puddlestheshark.com> wrote in message
news:OYLoaFvNFHA.204@.TK2MSFTNGP15.phx.gbl...
> It's not; it's whenever a report is run.
> A little more detail:
> We have a web application, let's say it's at www.url.com, which is not the
> same as the server's default web site. This site is secured using Forms
> Authentication. We wanted to add the Report Viewer to our application.
> What we did was to add the ReportServer virtual to the www.url.com
website,
> and add a page to our application with a ReportViewer control and direct
it
> to www.url.com/ReportServer. (We copied the ReportServer folder on the
> server, so we could set its configuration independent of the
> defaultip/ReportServer site.) Unfortunately, we had some difficulty
getting
> this virtual to work with Forms Auth -- we tried the sample Forms Auth
> validator, we tried just setting it to Forms Auth (hoping it would inherit
> the authentication from the parent site -- it didn't, it just kept
> redirecting its frame to our login page), and ultimately, we ended up just
> turning authentication off completely. (Yes, this is absolutely insecure,
> but we were unfortunately under "just make it work" pressure, and it was
the
> only way we could get the stupid login box to go away whenever a user
tried
> to run a report.)
> When adding the rs:ClearSession to the querystring, it appears to
annihilate
> the Session of our web app -- the error we're seeing is actually a page
that
> is displayed when our web app detects the Session object is no more (which
> usually only happens on a Session Timeout). As soon as we removed that
> parameter (fortunately we store this in Web.config), our apparent timeout
> problems went away immediately.
> But we're back at this same problem where a user can run a report, go to
> another part of the app and change data, come back to this same report,
and
> not see the updates immediately, despite the fact that all reports are set
> to "render with most recent data" and "do not cache" and the
> www.url.com/ReportServer virtual is set in IIS to "expire content
> immediately".
> "Bruce L-C [MVP]" <bruce_lcNOSPAM@.hotmail.com> wrote in message
> news:OIIcIpuNFHA.576@.TK2MSFTNGP15.phx.gbl...
> > Ahh, didn't know you were doing forms authentication.
> >
> > If the issue is only when you roll out a change then what you need to do
> > is
> > when you roll out a change the user might need to close IE and then
> > re-open
> > it.
> >
> >
> > --
> > Bruce Loehle-Conger
> > MVP SQL Server Reporting Services
> >
> > "DJM" <msnews@.puddlestheshark.com> wrote in message
> > news:OLCt4%23tNFHA.3704@.TK2MSFTNGP12.phx.gbl...
> >> I added the rs:ClearSession parameter, but now it's kicking my users
out
> > of
> >> the system (it's the only thing that changed, so this is definitely the
> >> source of the problem -- the web app is under forms authentication) --
it
> >> appears to be clearing out the whole session, not just anything related
> >> to
> >> the Report Server. This is extremely bad.
> >>
> >> "DJM" <msnews@.puddlestheshark.com> wrote in message
> >> news:%23Xg56aXNFHA.3296@.TK2MSFTNGP15.phx.gbl...
> >> > When I run the web-based report viewer
> >> > (http://url/ReportServer?<parameters>), it is caching the results. I
> > can
> >> > go to another part of my web app and change some data, but when I go
> > back
> >> > to the report, it doesn't reflect changes. Also, if I change the
> >> > report
> >> > and redeploy from Vis. Studio and hit the same URL for the report, I
> > don't
> >> > see the changes. {That is, until I hit the little "refresh" button
on
> > the
> >> > report viewer toolbar. The cache does "time out" eventually, but I
> >> > have
> >> > not tried measuring that time.}
> >> >
> >> > I've set the web site properties on the ReportServer virtual to
"Expire
> >> > Content Immediately." I've also checked the reports themselves and
> >> > made
> >> > sure the Execution properties have selected "Render this report with
> >> > the
> >> > most recent data" and "Do not cache temporary copies of this
report" --
> >> > both are true. So why aren't my updates reflected on the next page
hit
> >> > automatically?
> >> >
> >>
> >>
> >
> >
>|||Fortunately, in my organization we are able to use rs:ClearSession for
our current needs. If you can't use rs:ClearSession, the workaround we
have come up with is to add a dummy parameter to the URL. IE will only
show you the stale, cached copy of the report if the entire URL is
character-for-character identical. If you increment the dummy
parameter every time you click the link, then the URL's will be
different, and IE won't cache.
Creating the unique dummy parameter does require a tiny bit of
client-side JavaScript programming -- you can't use a simple static
HTML link. This was not a problem for us since we were usually
launching reports from buttons that already had code.
Hope this helps,
Ted
Bruce L-C [MVP] wrote:
> I have not done this so I am fresh out of ideas for you. Hopefully
someone
> else can jump in.
>
> --
> Bruce Loehle-Conger
> MVP SQL Server Reporting Services
> "DJM" <msnews@.puddlestheshark.com> wrote in message
> news:OYLoaFvNFHA.204@.TK2MSFTNGP15.phx.gbl...
> > It's not; it's whenever a report is run.
> >
> > A little more detail:
> > We have a web application, let's say it's at www.url.com, which is
not the
> > same as the server's default web site. This site is secured using
Forms
> > Authentication. We wanted to add the Report Viewer to our
application.
> > What we did was to add the ReportServer virtual to the www.url.com
> website,
> > and add a page to our application with a ReportViewer control and
direct
> it
> > to www.url.com/ReportServer. (We copied the ReportServer folder on
the
> > server, so we could set its configuration independent of the
> > defaultip/ReportServer site.) Unfortunately, we had some
difficulty
> getting
> > this virtual to work with Forms Auth -- we tried the sample Forms
Auth
> > validator, we tried just setting it to Forms Auth (hoping it would
inherit
> > the authentication from the parent site -- it didn't, it just kept
> > redirecting its frame to our login page), and ultimately, we ended
up just
> > turning authentication off completely. (Yes, this is absolutely
insecure,
> > but we were unfortunately under "just make it work" pressure, and
it was
> the
> > only way we could get the stupid login box to go away whenever a
user
> tried
> > to run a report.)
> >
> > When adding the rs:ClearSession to the querystring, it appears to
> annihilate
> > the Session of our web app -- the error we're seeing is actually a
page
> that
> > is displayed when our web app detects the Session object is no more
(which
> > usually only happens on a Session Timeout). As soon as we removed
that
> > parameter (fortunately we store this in Web.config), our apparent
timeout
> > problems went away immediately.
> >
> > But we're back at this same problem where a user can run a report,
go to
> > another part of the app and change data, come back to this same
report,
> and
> > not see the updates immediately, despite the fact that all reports
are set
> > to "render with most recent data" and "do not cache" and the
> > www.url.com/ReportServer virtual is set in IIS to "expire content
> > immediately".
> >|||Ted, that is a cool workaround. Creative solution.
Bruce Loehle-Conger
MVP SQL Server Reporting Services
"Ted K" <tkyi@.infotechsm.com> wrote in message
news:1112393836.495225.113290@.f14g2000cwb.googlegroups.com...
> Fortunately, in my organization we are able to use rs:ClearSession for
> our current needs. If you can't use rs:ClearSession, the workaround we
> have come up with is to add a dummy parameter to the URL. IE will only
> show you the stale, cached copy of the report if the entire URL is
> character-for-character identical. If you increment the dummy
> parameter every time you click the link, then the URL's will be
> different, and IE won't cache.
> Creating the unique dummy parameter does require a tiny bit of
> client-side JavaScript programming -- you can't use a simple static
> HTML link. This was not a problem for us since we were usually
> launching reports from buttons that already had code.
> Hope this helps,
> Ted
> Bruce L-C [MVP] wrote:
> > I have not done this so I am fresh out of ideas for you. Hopefully
> someone
> > else can jump in.
> >
> >
> > --
> > Bruce Loehle-Conger
> > MVP SQL Server Reporting Services
> >
> > "DJM" <msnews@.puddlestheshark.com> wrote in message
> > news:OYLoaFvNFHA.204@.TK2MSFTNGP15.phx.gbl...
> > > It's not; it's whenever a report is run.
> > >
> > > A little more detail:
> > > We have a web application, let's say it's at www.url.com, which is
> not the
> > > same as the server's default web site. This site is secured using
> Forms
> > > Authentication. We wanted to add the Report Viewer to our
> application.
> > > What we did was to add the ReportServer virtual to the www.url.com
> > website,
> > > and add a page to our application with a ReportViewer control and
> direct
> > it
> > > to www.url.com/ReportServer. (We copied the ReportServer folder on
> the
> > > server, so we could set its configuration independent of the
> > > defaultip/ReportServer site.) Unfortunately, we had some
> difficulty
> > getting
> > > this virtual to work with Forms Auth -- we tried the sample Forms
> Auth
> > > validator, we tried just setting it to Forms Auth (hoping it would
> inherit
> > > the authentication from the parent site -- it didn't, it just kept
> > > redirecting its frame to our login page), and ultimately, we ended
> up just
> > > turning authentication off completely. (Yes, this is absolutely
> insecure,
> > > but we were unfortunately under "just make it work" pressure, and
> it was
> > the
> > > only way we could get the stupid login box to go away whenever a
> user
> > tried
> > > to run a report.)
> > >
> > > When adding the rs:ClearSession to the querystring, it appears to
> > annihilate
> > > the Session of our web app -- the error we're seeing is actually a
> page
> > that
> > > is displayed when our web app detects the Session object is no more
> (which
> > > usually only happens on a Session Timeout). As soon as we removed
> that
> > > parameter (fortunately we store this in Web.config), our apparent
> timeout
> > > problems went away immediately.
> > >
> > > But we're back at this same problem where a user can run a report,
> go to
> > > another part of the app and change data, come back to this same
> report,
> > and
> > > not see the updates immediately, despite the fact that all reports
> are set
> > > to "render with most recent data" and "do not cache" and the
> > > www.url.com/ReportServer virtual is set in IIS to "expire content
> > > immediately".
> > >
>|||An interesting idea, but unfortunately it doesn't work. I added a "&rc:u="
+ DateTime.Now.Ticks.ToString() to the querystring, and it still shows me
the cached copy of the data. (If I try it without the "rc:" prefix, it
assumes a report parameter, and unless I add a parameter to all of our
reports, I get an error message from Report Server about passing in a
parameter that doesn't exist.)
"Ted K" <tkyi@.infotechsm.com> wrote in message
news:1112393836.495225.113290@.f14g2000cwb.googlegroups.com...
> Fortunately, in my organization we are able to use rs:ClearSession for
> our current needs. If you can't use rs:ClearSession, the workaround we
> have come up with is to add a dummy parameter to the URL. IE will only
> show you the stale, cached copy of the report if the entire URL is
> character-for-character identical. If you increment the dummy
> parameter every time you click the link, then the URL's will be
> different, and IE won't cache.
> Creating the unique dummy parameter does require a tiny bit of
> client-side JavaScript programming -- you can't use a simple static
> HTML link. This was not a problem for us since we were usually
> launching reports from buttons that already had code.
> Hope this helps,
> Ted
> Bruce L-C [MVP] wrote:
>> I have not done this so I am fresh out of ideas for you. Hopefully
> someone
>> else can jump in.
>>
>> --
>> Bruce Loehle-Conger
>> MVP SQL Server Reporting Services
>> "DJM" <msnews@.puddlestheshark.com> wrote in message
>> news:OYLoaFvNFHA.204@.TK2MSFTNGP15.phx.gbl...
>> > It's not; it's whenever a report is run.
>> >
>> > A little more detail:
>> > We have a web application, let's say it's at www.url.com, which is
> not the
>> > same as the server's default web site. This site is secured using
> Forms
>> > Authentication. We wanted to add the Report Viewer to our
> application.
>> > What we did was to add the ReportServer virtual to the www.url.com
>> website,
>> > and add a page to our application with a ReportViewer control and
> direct
>> it
>> > to www.url.com/ReportServer. (We copied the ReportServer folder on
> the
>> > server, so we could set its configuration independent of the
>> > defaultip/ReportServer site.) Unfortunately, we had some
> difficulty
>> getting
>> > this virtual to work with Forms Auth -- we tried the sample Forms
> Auth
>> > validator, we tried just setting it to Forms Auth (hoping it would
> inherit
>> > the authentication from the parent site -- it didn't, it just kept
>> > redirecting its frame to our login page), and ultimately, we ended
> up just
>> > turning authentication off completely. (Yes, this is absolutely
> insecure,
>> > but we were unfortunately under "just make it work" pressure, and
> it was
>> the
>> > only way we could get the stupid login box to go away whenever a
> user
>> tried
>> > to run a report.)
>> >
>> > When adding the rs:ClearSession to the querystring, it appears to
>> annihilate
>> > the Session of our web app -- the error we're seeing is actually a
> page
>> that
>> > is displayed when our web app detects the Session object is no more
> (which
>> > usually only happens on a Session Timeout). As soon as we removed
> that
>> > parameter (fortunately we store this in Web.config), our apparent
> timeout
>> > problems went away immediately.
>> >
>> > But we're back at this same problem where a user can run a report,
> go to
>> > another part of the app and change data, come back to this same
> report,
>> and
>> > not see the updates immediately, despite the fact that all reports
> are set
>> > to "render with most recent data" and "do not cache" and the
>> > www.url.com/ReportServer virtual is set in IIS to "expire content
>> > immediately".
>> >
>|||Sorry, DJM, I misspoke a little in my last post. Let me clarify. As
Bruce has explained, RS has to maintain session so it can handle
certain cases, such as moving to the next page or exporting to a new
format. For those cases, it is desirable that the report remain
unchanged for that user.
In order to implement the workaround, you have to modify the part of
the URL that RS cares about. So, yes, when I said a dummy parameter, I
really meant adding an extra parameter to your report. I realized that
my last post makes it sound like you can add any characters to the URL.
If you already have a zillion reports, then of course it will be a pain
to add a parameter to all of them. (I'd edit the XML directly, and
maybe try to set up some kind of smart search and replace, instead of
using Visual Studio by hand.) Unless you can resolve your
authentication issue, I think this is the way for you to go.
Ted
DJM wrote:
> An interesting idea, but unfortunately it doesn't work. I added a
"&rc:u="
> + DateTime.Now.Ticks.ToString() to the querystring, and it still
shows me
> the cached copy of the data. (If I try it without the "rc:" prefix,
it
> assumes a report parameter, and unless I add a parameter to all of
our
> reports, I get an error message from Report Server about passing in a
> parameter that doesn't exist.)
> "Ted K" <tkyi@.infotechsm.com> wrote in message
> news:1112393836.495225.113290@.f14g2000cwb.googlegroups.com...
> > Fortunately, in my organization we are able to use rs:ClearSession
for
> > our current needs. If you can't use rs:ClearSession, the
workaround we
> > have come up with is to add a dummy parameter to the URL. IE will
only
> > show you the stale, cached copy of the report if the entire URL is
> > character-for-character identical. If you increment the dummy
> > parameter every time you click the link, then the URL's will be
> > different, and IE won't cache.
> >
> > Creating the unique dummy parameter does require a tiny bit of
> > client-side JavaScript programming -- you can't use a simple static
> > HTML link. This was not a problem for us since we were usually
> > launching reports from buttons that already had code.
> >
> > Hope this helps,
> > Ted
> >|||Alright, I'll give that a try then. I still consider this a RS bug.
"Ted K" <tkyi@.infotechsm.com> wrote in message
news:1112633029.297136.68110@.g14g2000cwa.googlegroups.com...
> Sorry, DJM, I misspoke a little in my last post. Let me clarify. As
> Bruce has explained, RS has to maintain session so it can handle
> certain cases, such as moving to the next page or exporting to a new
> format. For those cases, it is desirable that the report remain
> unchanged for that user.
> In order to implement the workaround, you have to modify the part of
> the URL that RS cares about. So, yes, when I said a dummy parameter, I
> really meant adding an extra parameter to your report. I realized that
> my last post makes it sound like you can add any characters to the URL.
> If you already have a zillion reports, then of course it will be a pain
> to add a parameter to all of them. (I'd edit the XML directly, and
> maybe try to set up some kind of smart search and replace, instead of
> using Visual Studio by hand.) Unless you can resolve your
> authentication issue, I think this is the way for you to go.
> Ted
> DJM wrote:
>> An interesting idea, but unfortunately it doesn't work. I added a
> "&rc:u="
>> + DateTime.Now.Ticks.ToString() to the querystring, and it still
> shows me
>> the cached copy of the data. (If I try it without the "rc:" prefix,
> it
>> assumes a report parameter, and unless I add a parameter to all of
> our
>> reports, I get an error message from Report Server about passing in a
>> parameter that doesn't exist.)
>> "Ted K" <tkyi@.infotechsm.com> wrote in message
>> news:1112393836.495225.113290@.f14g2000cwb.googlegroups.com...
>> > Fortunately, in my organization we are able to use rs:ClearSession
> for
>> > our current needs. If you can't use rs:ClearSession, the
> workaround we
>> > have come up with is to add a dummy parameter to the URL. IE will
> only
>> > show you the stale, cached copy of the report if the entire URL is
>> > character-for-character identical. If you increment the dummy
>> > parameter every time you click the link, then the URL's will be
>> > different, and IE won't cache.
>> >
>> > Creating the unique dummy parameter does require a tiny bit of
>> > client-side JavaScript programming -- you can't use a simple static
>> > HTML link. This was not a problem for us since we were usually
>> > launching reports from buttons that already had code.
>> >
>> > Hope this helps,
>> > Ted
>> >
>|||Ok, that worked. I ended up having to spend a couple days and doing a lot
of it by hand (for some reason, I couldn't navigate the XML with code very
easily - SelectNodes didn't want to find nodes I knew existed, even when I
specified the correct namespace), but adding a text parameter and passing in
DateTime.Now.Ticks.ToString() on execute (thankfully there are only two
report viewing functions in our app) now forces the reports to pull current
data. Thanks for the help!
"Ted K" <tkyi@.infotechsm.com> wrote in message
news:1112633029.297136.68110@.g14g2000cwa.googlegroups.com...
> Sorry, DJM, I misspoke a little in my last post. Let me clarify. As
> Bruce has explained, RS has to maintain session so it can handle
> certain cases, such as moving to the next page or exporting to a new
> format. For those cases, it is desirable that the report remain
> unchanged for that user.
> In order to implement the workaround, you have to modify the part of
> the URL that RS cares about. So, yes, when I said a dummy parameter, I
> really meant adding an extra parameter to your report. I realized that
> my last post makes it sound like you can add any characters to the URL.
> If you already have a zillion reports, then of course it will be a pain
> to add a parameter to all of them. (I'd edit the XML directly, and
> maybe try to set up some kind of smart search and replace, instead of
> using Visual Studio by hand.) Unless you can resolve your
> authentication issue, I think this is the way for you to go.
> Ted
> DJM wrote:
>> An interesting idea, but unfortunately it doesn't work. I added a
> "&rc:u="
>> + DateTime.Now.Ticks.ToString() to the querystring, and it still
> shows me
>> the cached copy of the data. (If I try it without the "rc:" prefix,
> it
>> assumes a report parameter, and unless I add a parameter to all of
> our
>> reports, I get an error message from Report Server about passing in a
>> parameter that doesn't exist.)
>> "Ted K" <tkyi@.infotechsm.com> wrote in message
>> news:1112393836.495225.113290@.f14g2000cwb.googlegroups.com...
>> > Fortunately, in my organization we are able to use rs:ClearSession
> for
>> > our current needs. If you can't use rs:ClearSession, the
> workaround we
>> > have come up with is to add a dummy parameter to the URL. IE will
> only
>> > show you the stale, cached copy of the report if the entire URL is
>> > character-for-character identical. If you increment the dummy
>> > parameter every time you click the link, then the URL's will be
>> > different, and IE won't cache.
>> >
>> > Creating the unique dummy parameter does require a tiny bit of
>> > client-side JavaScript programming -- you can't use a simple static
>> > HTML link. This was not a problem for us since we were usually
>> > launching reports from buttons that already had code.
>> >
>> > Hope this helps,
>> > Ted
>> >
>