ASP.Net charting tools image disappears using SQL Server session

0
votes

We're using the ASP.Net charting tools (version 3.5) and would like to store the chart images in SQL Server session. Here's the section in the web.config:

<add key="ChartImageHandler" value="storage=session;timeout=20;" />

And our session setting in the web.config looks like this:

<sessionState mode="SQLServer" sqlConnectionString="Data Source={sql server name}; Integrated Security=SSPI;" cookieless="false" timeout="30"/>

The chart image works fine the first time a page is loaded. However, it fails to load every time after that. We get the red X/image not found graphic. It appears as if the image isn't saved properly to the session, but changing the "timeout" value doesn't help.

The file storage option version does work:

<add key="ChartImageHandler" value="Storage=file;Timeout=800;Dir=C:\Directory\TempChartFiles;"/>

We'd, however, prefer to use the SQL Server session option instead. Is there any way to get the SQL Server session option to work with the ASP.Net charting tools?

1
asp.netchartsasp.net-charts

1 Answers

0
votes

First, I am not sure where you are setting up your key. Is it in or have you set it up somewhere more specific. Next, how is teh code set up to Render.

From what I see, you are expecting some magic ASP.NET fairy to store the value and automagically pull it from session for you, which is not how session works.

In addition, I am not sure what the business problem is, so i am not even sure if session is the best place to store. ASP.NET has a wonderful set of caching options that can be more user specific or more application specific, depending on your needs. It is also not automagic, but often works better than using Session to store things.

The issue here, as I see it, is you are missing some code to actually handle the session storing, and not a SQL Server issue. I will state that SQL Server may be a bad Session option in this case, especially if you end up with larger graphics. You can greatly reduce your scalability over other caching solutions. In other words, I am not convinced session is a good option in any case, but possibly worse with SQL Server.

The main reason to use SQL Server for session state is one of the following:

  1. Need a distributed solution, but cannot use a session server
  2. need to be able to recover from a worker process failure, etc., and still maintain session

If you have more code and can follow up with a more specific business reason, you will likely get more thorough answers on how to solve the problem.