State database

  • Thread starter Thread starter Duke (AN247)
  • Start date Start date
D

Duke (AN247)

We are setting up a web farm and want to store session state on a SQL Server
2005 Enterprise sp2 database. But when the web sites try to access the
session state we get the error...

Unable to use SQL Server because ASP.NET version 2.0 Session State is not
installed on the SQL server.

We installed the custom state database using...
aspnet_regsql -S mysvrname -E -ssadd -sstype c -d mydbname
....and can see the database.

The web.config has
<sessionState
mode="SQLServer"
cookieless="false"
allowCustomSqlDatabase="true"
timeout="20"
sqlConnectionString="sessionConStr"/>

Where sessionConStr is defined in the <connectionStrings> section...
<add name="sessionConStr"
connectionString="server=myservername;database=mydbname;Trusted_Connection=yes;Connection Timeout=10;" providerName="System.Data.SqlClient"/>
I'm confident in the connection string because if I change it to point to a
non existent database then I get a login failed error. So I know that the
connection string is finding the database.

Any ideas why we get the error message?
Unable to use SQL Server because ASP.NET version 2.0 Session State is not
installed on the SQL server.

Thanks,
Andrew
 
Where sessionConStr is defined in the <connectionStrings> section...
<add name="sessionConStr"
connectionString="server=myservername;database=mydbname;Trusted_Connect
ion=yes;Connection Timeout=10;" providerName="System.Data.SqlClient"/>
I'm confident in the connection string because if I change it to point
to a non existent database then I get a login failed error. So I know
that the connection string is finding the database.

Any ideas why we get the error message?
Unable to use SQL Server because ASP.NET version 2.0 Session State is
not installed on the SQL server.

ASP.NET runs under the Network Services account on Windows 2003 - does that
account have access to your database? If not, you may want to hard code in
the log in credentials into your connection string.
 
Thanks for your input. We are using a specific domain account rather than the
default account. The domain account then uses a trusted connection to the
database.
I suppose I could get the dbas to give the account db_owner rights to see if
that cures it, and if it did we could start reducing permissions from there.
 
Solved it. The account needed execute permissions on all the stored procedures.
It doesn't seem to need db_datareader.
 
Back
Top