images, stream ids, etc

ok, I have finally made my mind about how I will be doing the displaying
images in my site when I am using soap access ... here is the thread I posted
before:
http://www.microsoft.com/sql/community/newsgroups/dgbrowser/en-us/default.mspx?&guid=&sloc=en-us&dg=microsoft.public.sqlserver.reportingsvcs&p=1&tid=9888dd27-6e44-4c0d-8293-4d3a6ae93860&mid=e8ede148-3266-4bd0-ba1c-4f65f4197643
as long as I understand stream ids are unique, so the way I am doing this is
as follows:
1) I have an aspx page to render my reports
2) I have a grid to display the parameters, which definition I grab
dinamically trough soap access ... which gives me nice things, like types,
valid values (which are translated to dropdownlists:P), default values,
dependencies, etc ...
3) Once the user clicks the view report button (there are others, as export,
...) and the parameters have been validated I get the report from Reporting
Services, indicating that the streamroot is a special page I will have to
display images, indicating in the query string the parameters values and
related stuff selected by the user ...
4) As I said I will have a page to display the images. Right at the moment
the user is accesing this page, it will make the call to the reporting
services, thus I wont be having the need to handle saving the images and then
deleting them.
5) I dont want that page to be asking for an image it has already handled,
which might in turn be an image that appears in the very same report several
times ... In order to do this I will be turning asp.net cache on in that
page, so asp.net will handle saving it temporarily ...
The Question:
Does that way of handling the image is good enough when talking about
performance? ...
in the mean time, I will be doing that image page, and testing all this ...
I would highly apreciate any comments on this ...Eglasius,
Did you have success with this? I have done nearly the exact same thing,
but have found a couple of problems with chart images.
I first wanted (and prefer) to allow the client browser to cache the entire
page so that as they drill through the report charts, they can easily go back
by using the browser's back button -- requiring no return to the server.
However, I found that the streamIDs are NOT unique in some cases. For
example, I have a pie chart that with one set of data has a stream id of
C_21_S. The user drills through this chart and the chart is now rendered
using different data which obviously produces a different looking chart.
BUT! -- the stream id is still C_21_S! The browser of course cached the last
version of the image so the report renders with the wrong chart.
I considered a couple of options:
1) Adding something unique to the streamroot in addition to the
not-so-unique streamid. Then, the client browser would consider the image
url unique even if the streamid is not. I guess I would have to generate a
guid to use in the stream root. Perhasps something like this:
"<StreamRoot>/Reports/Report/ImgProxy.aspx?guid=" & GetGuid()&
"&imageid=</StreamRoot>"
2) Second option would be to send HTTP headers to prevent caching of just
the image elements -- I think this is possible, but wanted to avoid it.
Thoughts anyone?
"eglasius" wrote:
> ok, I have finally made my mind about how I will be doing the displaying
> images in my site when I am using soap access ... here is the thread I posted
> before:
> http://www.microsoft.com/sql/community/newsgroups/dgbrowser/en-us/default.mspx?&guid=&sloc=en-us&dg=microsoft.public.sqlserver.reportingsvcs&p=1&tid=9888dd27-6e44-4c0d-8293-4d3a6ae93860&mid=e8ede148-3266-4bd0-ba1c-4f65f4197643
> as long as I understand stream ids are unique, so the way I am doing this is
> as follows:
> 1) I have an aspx page to render my reports
> 2) I have a grid to display the parameters, which definition I grab
> dinamically trough soap access ... which gives me nice things, like types,
> valid values (which are translated to dropdownlists:P), default values,
> dependencies, etc ...
> 3) Once the user clicks the view report button (there are others, as export,
> ...) and the parameters have been validated I get the report from Reporting
> Services, indicating that the streamroot is a special page I will have to
> display images, indicating in the query string the parameters values and
> related stuff selected by the user ...
> 4) As I said I will have a page to display the images. Right at the moment
> the user is accesing this page, it will make the call to the reporting
> services, thus I wont be having the need to handle saving the images and then
> deleting them.
> 5) I dont want that page to be asking for an image it has already handled,
> which might in turn be an image that appears in the very same report several
> times ... In order to do this I will be turning asp.net cache on in that
> page, so asp.net will handle saving it temporarily ...
> The Question:
> Does that way of handling the image is good enough when talking about
> performance? ...
> in the mean time, I will be doing that image page, and testing all this ...
> I would highly apreciate any comments on this ...|||Well, my case was a very particular one, since I wasnt using dynamic images
(it was a static logo) yet, but I did want the image to be grabbed from the
report. The solution I used also needed to be compatible in case I were to
use dynamic images.
The thing is so far it has worked well, but we are using any dynamic image.
Because of this, I have no clue if I would experience the very same problem
that is happening to you.
On the other hand, I do have to say that at the end I didn't have to turn
asp.net cache on for the image served, since the browser seems to ask for the
image only once regardless of configuration (what I was worried about was a
browser with the "every visit to the page" configuration turned on asking for
a 20 pages report and ending up getting the image 20 times, which at the end
didn't happen).
In your case I would check if the drilled down page is actually being asked
to asp.net (or it is coming from the cache), and if not using a guid sounds
reasonable. If you have any other "unique" value (that relates to drilling
down) you are already using at hand, you might as well use that one instead.
One thing that really grabbed my attention, is that you aren't including
which report or params in the stream root. Unless your report doesn't have
parameters, all of them are fixed or your are saving them in some middle
object, I don't seem to understand how your are doing it.
I say so, because of this:
reports.RenderStream(report, format, streamId, null, deviceInfo, parms, out
encoding, out mimeType);
when getting the image one sends the report + streamId+parms.
"David Swanson" wrote:
> Eglasius,
> Did you have success with this? I have done nearly the exact same thing,
> but have found a couple of problems with chart images.
> I first wanted (and prefer) to allow the client browser to cache the entire
> page so that as they drill through the report charts, they can easily go back
> by using the browser's back button -- requiring no return to the server.
> However, I found that the streamIDs are NOT unique in some cases. For
> example, I have a pie chart that with one set of data has a stream id of
> C_21_S. The user drills through this chart and the chart is now rendered
> using different data which obviously produces a different looking chart.
> BUT! -- the stream id is still C_21_S! The browser of course cached the last
> version of the image so the report renders with the wrong chart.
> I considered a couple of options:
> 1) Adding something unique to the streamroot in addition to the
> not-so-unique streamid. Then, the client browser would consider the image
> url unique even if the streamid is not. I guess I would have to generate a
> guid to use in the stream root. Perhasps something like this:
> "<StreamRoot>/Reports/Report/ImgProxy.aspx?guid=" & GetGuid()&
> "&imageid=</StreamRoot>"
> 2) Second option would be to send HTTP headers to prevent caching of just
> the image elements -- I think this is possible, but wanted to avoid it.
> Thoughts anyone?
> "eglasius" wrote:
> > ok, I have finally made my mind about how I will be doing the displaying
> > images in my site when I am using soap access ... here is the thread I posted
> > before:
> > http://www.microsoft.com/sql/community/newsgroups/dgbrowser/en-us/default.mspx?&guid=&sloc=en-us&dg=microsoft.public.sqlserver.reportingsvcs&p=1&tid=9888dd27-6e44-4c0d-8293-4d3a6ae93860&mid=e8ede148-3266-4bd0-ba1c-4f65f4197643
> >
> > as long as I understand stream ids are unique, so the way I am doing this is
> > as follows:
> > 1) I have an aspx page to render my reports
> > 2) I have a grid to display the parameters, which definition I grab
> > dinamically trough soap access ... which gives me nice things, like types,
> > valid values (which are translated to dropdownlists:P), default values,
> > dependencies, etc ...
> > 3) Once the user clicks the view report button (there are others, as export,
> > ...) and the parameters have been validated I get the report from Reporting
> > Services, indicating that the streamroot is a special page I will have to
> > display images, indicating in the query string the parameters values and
> > related stuff selected by the user ...
> > 4) As I said I will have a page to display the images. Right at the moment
> > the user is accesing this page, it will make the call to the reporting
> > services, thus I wont be having the need to handle saving the images and then
> > deleting them.
> > 5) I dont want that page to be asking for an image it has already handled,
> > which might in turn be an image that appears in the very same report several
> > times ... In order to do this I will be turning asp.net cache on in that
> > page, so asp.net will handle saving it temporarily ...
> >
> > The Question:
> > Does that way of handling the image is good enough when talking about
> > performance? ...
> >
> > in the mean time, I will be doing that image page, and testing all this ...
> > I would highly apreciate any comments on this ...|||Thanks for your prompt reply!
Yes, I was being lazy and store the report params in the user session. We
have a boat load of params that are used in a custom DPE and it was a
headache to format them all on the querystring, so I just keep the params
collection in the session and the imageproxy page gets it from there.
Unless someone from the MS team has a better idea, I think I will have to
include a guid. The other really odd thing is that the report has a pie
chart and a stacked bar chart. The pie chart always seems to use the same
stream id, but the stacked bar chart has always created a unique id --so far.
Can anyone from the MS Reporting Services team explain the behavior of how
the streamids are generated for the dynamic images produced by the chart
objects?
Much appreciated, David
"eglasius" wrote:
> Well, my case was a very particular one, since I wasnt using dynamic images
> (it was a static logo) yet, but I did want the image to be grabbed from the
> report. The solution I used also needed to be compatible in case I were to
> use dynamic images.
> The thing is so far it has worked well, but we are using any dynamic image.
> Because of this, I have no clue if I would experience the very same problem
> that is happening to you.
> On the other hand, I do have to say that at the end I didn't have to turn
> asp.net cache on for the image served, since the browser seems to ask for the
> image only once regardless of configuration (what I was worried about was a
> browser with the "every visit to the page" configuration turned on asking for
> a 20 pages report and ending up getting the image 20 times, which at the end
> didn't happen).
> In your case I would check if the drilled down page is actually being asked
> to asp.net (or it is coming from the cache), and if not using a guid sounds
> reasonable. If you have any other "unique" value (that relates to drilling
> down) you are already using at hand, you might as well use that one instead.
> One thing that really grabbed my attention, is that you aren't including
> which report or params in the stream root. Unless your report doesn't have
> parameters, all of them are fixed or your are saving them in some middle
> object, I don't seem to understand how your are doing it.
> I say so, because of this:
> reports.RenderStream(report, format, streamId, null, deviceInfo, parms, out
> encoding, out mimeType);
> when getting the image one sends the report + streamId+parms.
> "David Swanson" wrote:
> > Eglasius,
> >
> > Did you have success with this? I have done nearly the exact same thing,
> > but have found a couple of problems with chart images.
> >
> > I first wanted (and prefer) to allow the client browser to cache the entire
> > page so that as they drill through the report charts, they can easily go back
> > by using the browser's back button -- requiring no return to the server.
> >
> > However, I found that the streamIDs are NOT unique in some cases. For
> > example, I have a pie chart that with one set of data has a stream id of
> > C_21_S. The user drills through this chart and the chart is now rendered
> > using different data which obviously produces a different looking chart.
> > BUT! -- the stream id is still C_21_S! The browser of course cached the last
> > version of the image so the report renders with the wrong chart.
> >
> > I considered a couple of options:
> >
> > 1) Adding something unique to the streamroot in addition to the
> > not-so-unique streamid. Then, the client browser would consider the image
> > url unique even if the streamid is not. I guess I would have to generate a
> > guid to use in the stream root. Perhasps something like this:
> >
> > "<StreamRoot>/Reports/Report/ImgProxy.aspx?guid=" & GetGuid()&
> > "&imageid=</StreamRoot>"
> >
> > 2) Second option would be to send HTTP headers to prevent caching of just
> > the image elements -- I think this is possible, but wanted to avoid it.
> >
> > Thoughts anyone?
> >
> > "eglasius" wrote:
> >
> > > ok, I have finally made my mind about how I will be doing the displaying
> > > images in my site when I am using soap access ... here is the thread I posted
> > > before:
> > > http://www.microsoft.com/sql/community/newsgroups/dgbrowser/en-us/default.mspx?&guid=&sloc=en-us&dg=microsoft.public.sqlserver.reportingsvcs&p=1&tid=9888dd27-6e44-4c0d-8293-4d3a6ae93860&mid=e8ede148-3266-4bd0-ba1c-4f65f4197643
> > >
> > > as long as I understand stream ids are unique, so the way I am doing this is
> > > as follows:
> > > 1) I have an aspx page to render my reports
> > > 2) I have a grid to display the parameters, which definition I grab
> > > dinamically trough soap access ... which gives me nice things, like types,
> > > valid values (which are translated to dropdownlists:P), default values,
> > > dependencies, etc ...
> > > 3) Once the user clicks the view report button (there are others, as export,
> > > ...) and the parameters have been validated I get the report from Reporting
> > > Services, indicating that the streamroot is a special page I will have to
> > > display images, indicating in the query string the parameters values and
> > > related stuff selected by the user ...
> > > 4) As I said I will have a page to display the images. Right at the moment
> > > the user is accesing this page, it will make the call to the reporting
> > > services, thus I wont be having the need to handle saving the images and then
> > > deleting them.
> > > 5) I dont want that page to be asking for an image it has already handled,
> > > which might in turn be an image that appears in the very same report several
> > > times ... In order to do this I will be turning asp.net cache on in that
> > > page, so asp.net will handle saving it temporarily ...
> > >
> > > The Question:
> > > Does that way of handling the image is good enough when talking about
> > > performance? ...
> > >
> > > in the mean time, I will be doing that image page, and testing all this ...
> > > I would highly apreciate any comments on this ...|||FYI: I did add a guid and it works perfectly now. I still would like MS to
explain to the newsgroup how streamids are created and why they would not be
unique for a dynamic chart image. Seems like a bug to me.
"David Swanson" wrote:
> Thanks for your prompt reply!
> Yes, I was being lazy and store the report params in the user session. We
> have a boat load of params that are used in a custom DPE and it was a
> headache to format them all on the querystring, so I just keep the params
> collection in the session and the imageproxy page gets it from there.
> Unless someone from the MS team has a better idea, I think I will have to
> include a guid. The other really odd thing is that the report has a pie
> chart and a stacked bar chart. The pie chart always seems to use the same
> stream id, but the stacked bar chart has always created a unique id --so far.
>
> Can anyone from the MS Reporting Services team explain the behavior of how
> the streamids are generated for the dynamic images produced by the chart
> objects?
> Much appreciated, David
> "eglasius" wrote:
> > Well, my case was a very particular one, since I wasnt using dynamic images
> > (it was a static logo) yet, but I did want the image to be grabbed from the
> > report. The solution I used also needed to be compatible in case I were to
> > use dynamic images.
> >
> > The thing is so far it has worked well, but we are using any dynamic image.
> > Because of this, I have no clue if I would experience the very same problem
> > that is happening to you.
> >
> > On the other hand, I do have to say that at the end I didn't have to turn
> > asp.net cache on for the image served, since the browser seems to ask for the
> > image only once regardless of configuration (what I was worried about was a
> > browser with the "every visit to the page" configuration turned on asking for
> > a 20 pages report and ending up getting the image 20 times, which at the end
> > didn't happen).
> >
> > In your case I would check if the drilled down page is actually being asked
> > to asp.net (or it is coming from the cache), and if not using a guid sounds
> > reasonable. If you have any other "unique" value (that relates to drilling
> > down) you are already using at hand, you might as well use that one instead.
> >
> > One thing that really grabbed my attention, is that you aren't including
> > which report or params in the stream root. Unless your report doesn't have
> > parameters, all of them are fixed or your are saving them in some middle
> > object, I don't seem to understand how your are doing it.
> > I say so, because of this:
> > reports.RenderStream(report, format, streamId, null, deviceInfo, parms, out
> > encoding, out mimeType);
> > when getting the image one sends the report + streamId+parms.
> >
> > "David Swanson" wrote:
> >
> > > Eglasius,
> > >
> > > Did you have success with this? I have done nearly the exact same thing,
> > > but have found a couple of problems with chart images.
> > >
> > > I first wanted (and prefer) to allow the client browser to cache the entire
> > > page so that as they drill through the report charts, they can easily go back
> > > by using the browser's back button -- requiring no return to the server.
> > >
> > > However, I found that the streamIDs are NOT unique in some cases. For
> > > example, I have a pie chart that with one set of data has a stream id of
> > > C_21_S. The user drills through this chart and the chart is now rendered
> > > using different data which obviously produces a different looking chart.
> > > BUT! -- the stream id is still C_21_S! The browser of course cached the last
> > > version of the image so the report renders with the wrong chart.
> > >
> > > I considered a couple of options:
> > >
> > > 1) Adding something unique to the streamroot in addition to the
> > > not-so-unique streamid. Then, the client browser would consider the image
> > > url unique even if the streamid is not. I guess I would have to generate a
> > > guid to use in the stream root. Perhasps something like this:
> > >
> > > "<StreamRoot>/Reports/Report/ImgProxy.aspx?guid=" & GetGuid()&
> > > "&imageid=</StreamRoot>"
> > >
> > > 2) Second option would be to send HTTP headers to prevent caching of just
> > > the image elements -- I think this is possible, but wanted to avoid it.
> > >
> > > Thoughts anyone?
> > >
> > > "eglasius" wrote:
> > >
> > > > ok, I have finally made my mind about how I will be doing the displaying
> > > > images in my site when I am using soap access ... here is the thread I posted
> > > > before:
> > > > http://www.microsoft.com/sql/community/newsgroups/dgbrowser/en-us/default.mspx?&guid=&sloc=en-us&dg=microsoft.public.sqlserver.reportingsvcs&p=1&tid=9888dd27-6e44-4c0d-8293-4d3a6ae93860&mid=e8ede148-3266-4bd0-ba1c-4f65f4197643
> > > >
> > > > as long as I understand stream ids are unique, so the way I am doing this is
> > > > as follows:
> > > > 1) I have an aspx page to render my reports
> > > > 2) I have a grid to display the parameters, which definition I grab
> > > > dinamically trough soap access ... which gives me nice things, like types,
> > > > valid values (which are translated to dropdownlists:P), default values,
> > > > dependencies, etc ...
> > > > 3) Once the user clicks the view report button (there are others, as export,
> > > > ...) and the parameters have been validated I get the report from Reporting
> > > > Services, indicating that the streamroot is a special page I will have to
> > > > display images, indicating in the query string the parameters values and
> > > > related stuff selected by the user ...
> > > > 4) As I said I will have a page to display the images. Right at the moment
> > > > the user is accesing this page, it will make the call to the reporting
> > > > services, thus I wont be having the need to handle saving the images and then
> > > > deleting them.
> > > > 5) I dont want that page to be asking for an image it has already handled,
> > > > which might in turn be an image that appears in the very same report several
> > > > times ... In order to do this I will be turning asp.net cache on in that
> > > > page, so asp.net will handle saving it temporarily ...
> > > >
> > > > The Question:
> > > > Does that way of handling the image is good enough when talking about
> > > > performance? ...
> > > >
> > > > in the mean time, I will be doing that image page, and testing all this ...
> > > > I would highly apreciate any comments on this ...|||> > Yes, I was being lazy and store the report params in the user session. We
> > have a boat load of params that are used in a custom DPE and it was a
> > headache to format them all on the querystring, so I just keep the params
> > collection in the session and the imageproxy page gets it from there.
As long as the user doesn't open different reports at the same time (it
hardly should happen ...) and you don't have an incredibly large amount of
users, it is ok :)
I also wan't to know if it is a bug or a behavior by design (and why) ...
"David Swanson" wrote:
> FYI: I did add a guid and it works perfectly now. I still would like MS to
> explain to the newsgroup how streamids are created and why they would not be
> unique for a dynamic chart image. Seems like a bug to me.
> "David Swanson" wrote:
> > Thanks for your prompt reply!
> >
> > Yes, I was being lazy and store the report params in the user session. We
> > have a boat load of params that are used in a custom DPE and it was a
> > headache to format them all on the querystring, so I just keep the params
> > collection in the session and the imageproxy page gets it from there.
> >
> > Unless someone from the MS team has a better idea, I think I will have to
> > include a guid. The other really odd thing is that the report has a pie
> > chart and a stacked bar chart. The pie chart always seems to use the same
> > stream id, but the stacked bar chart has always created a unique id --so far.
> >
> >
> > Can anyone from the MS Reporting Services team explain the behavior of how
> > the streamids are generated for the dynamic images produced by the chart
> > objects?
> >
> > Much appreciated, David
> >
> > "eglasius" wrote:
> >
> > > Well, my case was a very particular one, since I wasnt using dynamic images
> > > (it was a static logo) yet, but I did want the image to be grabbed from the
> > > report. The solution I used also needed to be compatible in case I were to
> > > use dynamic images.
> > >
> > > The thing is so far it has worked well, but we are using any dynamic image.
> > > Because of this, I have no clue if I would experience the very same problem
> > > that is happening to you.
> > >
> > > On the other hand, I do have to say that at the end I didn't have to turn
> > > asp.net cache on for the image served, since the browser seems to ask for the
> > > image only once regardless of configuration (what I was worried about was a
> > > browser with the "every visit to the page" configuration turned on asking for
> > > a 20 pages report and ending up getting the image 20 times, which at the end
> > > didn't happen).
> > >
> > > In your case I would check if the drilled down page is actually being asked
> > > to asp.net (or it is coming from the cache), and if not using a guid sounds
> > > reasonable. If you have any other "unique" value (that relates to drilling
> > > down) you are already using at hand, you might as well use that one instead.
> > >
> > > One thing that really grabbed my attention, is that you aren't including
> > > which report or params in the stream root. Unless your report doesn't have
> > > parameters, all of them are fixed or your are saving them in some middle
> > > object, I don't seem to understand how your are doing it.
> > > I say so, because of this:
> > > reports.RenderStream(report, format, streamId, null, deviceInfo, parms, out
> > > encoding, out mimeType);
> > > when getting the image one sends the report + streamId+parms.
> > >
> > > "David Swanson" wrote:
> > >
> > > > Eglasius,
> > > >
> > > > Did you have success with this? I have done nearly the exact same thing,
> > > > but have found a couple of problems with chart images.
> > > >
> > > > I first wanted (and prefer) to allow the client browser to cache the entire
> > > > page so that as they drill through the report charts, they can easily go back
> > > > by using the browser's back button -- requiring no return to the server.
> > > >
> > > > However, I found that the streamIDs are NOT unique in some cases. For
> > > > example, I have a pie chart that with one set of data has a stream id of
> > > > C_21_S. The user drills through this chart and the chart is now rendered
> > > > using different data which obviously produces a different looking chart.
> > > > BUT! -- the stream id is still C_21_S! The browser of course cached the last
> > > > version of the image so the report renders with the wrong chart.
> > > >
> > > > I considered a couple of options:
> > > >
> > > > 1) Adding something unique to the streamroot in addition to the
> > > > not-so-unique streamid. Then, the client browser would consider the image
> > > > url unique even if the streamid is not. I guess I would have to generate a
> > > > guid to use in the stream root. Perhasps something like this:
> > > >
> > > > "<StreamRoot>/Reports/Report/ImgProxy.aspx?guid=" & GetGuid()&
> > > > "&imageid=</StreamRoot>"
> > > >
> > > > 2) Second option would be to send HTTP headers to prevent caching of just
> > > > the image elements -- I think this is possible, but wanted to avoid it.
> > > >
> > > > Thoughts anyone?
> > > >
> > > > "eglasius" wrote:
> > > >
> > > > > ok, I have finally made my mind about how I will be doing the displaying
> > > > > images in my site when I am using soap access ... here is the thread I posted
> > > > > before:
> > > > > http://www.microsoft.com/sql/community/newsgroups/dgbrowser/en-us/default.mspx?&guid=&sloc=en-us&dg=microsoft.public.sqlserver.reportingsvcs&p=1&tid=9888dd27-6e44-4c0d-8293-4d3a6ae93860&mid=e8ede148-3266-4bd0-ba1c-4f65f4197643
> > > > >
> > > > > as long as I understand stream ids are unique, so the way I am doing this is
> > > > > as follows:
> > > > > 1) I have an aspx page to render my reports
> > > > > 2) I have a grid to display the parameters, which definition I grab
> > > > > dinamically trough soap access ... which gives me nice things, like types,
> > > > > valid values (which are translated to dropdownlists:P), default values,
> > > > > dependencies, etc ...
> > > > > 3) Once the user clicks the view report button (there are others, as export,
> > > > > ...) and the parameters have been validated I get the report from Reporting
> > > > > Services, indicating that the streamroot is a special page I will have to
> > > > > display images, indicating in the query string the parameters values and
> > > > > related stuff selected by the user ...
> > > > > 4) As I said I will have a page to display the images. Right at the moment
> > > > > the user is accesing this page, it will make the call to the reporting
> > > > > services, thus I wont be having the need to handle saving the images and then
> > > > > deleting them.
> > > > > 5) I dont want that page to be asking for an image it has already handled,
> > > > > which might in turn be an image that appears in the very same report several
> > > > > times ... In order to do this I will be turning asp.net cache on in that
> > > > > page, so asp.net will handle saving it temporarily ...
> > > > >
> > > > > The Question:
> > > > > Does that way of handling the image is good enough when talking about
> > > > > performance? ...
> > > > >
> > > > > in the mean time, I will be doing that image page, and testing all this ...
> > > > > I would highly apreciate any comments on this ...|||thanks you guys!.. I have been having a similar problem.
Recently we went live with reporting services. We are showing some charts,
and everything works fine the first time you show a chart. Subsequent charts
all show the image from the first chart. Hitting ctrl-R gets rid of the
problem, but this is undesirable (users would be confused). I took your idea
about slapping a GUID of some sort to the streamroot so that each request the
browser gets the image from the server.
Thanks again you guys!
Happy new years!