Timeline for Configuring private sessionState database raises runtime error:
Current License: CC BY-SA 3.0
8 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 4, 2016 at 15:37 | comment | added | eat-sleep-code | This answer along with @DmytroShevchenko feedback got me headed down the right path. The account needs access to select, insert, and delete data in the tempdb. Sitecore_sessions points to tables in the tempdb. | |
| Oct 4, 2016 at 15:34 | vote | accept | eat-sleep-code | ||
| Sep 27, 2016 at 23:04 | comment | added | Dmytro Shevchenko |
@MarkCassidy Sitecore's SqlSessionStateProvider is being used, according to the stack trace. ASP.NET SQL session state provider is not used.
|
|
| Sep 27, 2016 at 22:34 | comment | added | Mark Cassidy♦ | It's admittedly been a while since I used Sitecore's SQL Session state. I would still assume; if you replaced ASPState with Sitecore_Session in my above proposal (and grant the datareader/datawriter rights) - it should bring you further along. | |
| Sep 27, 2016 at 22:31 | comment | added | eat-sleep-code | I have a standard ASPState database the works fine. It is only when I try to switch to point to Sitecore_Sessions that it fails. | |
| Sep 27, 2016 at 22:29 | comment | added | Mark Cassidy♦ | It is. But you're not making it that far. Your exeption comes from System.Web.SessionState.SessionStateModule.InitModuleFromConfig - so the basic SQL Session Management doesn't even finish firing up. | |
| Sep 27, 2016 at 22:28 | comment | added | eat-sleep-code | So, I can just use the standard ASPState database setup? I thought Sitecore_Sessions was special which was the whole reason I was trying to leverage it. | |
| Sep 27, 2016 at 22:23 | history | answered | Mark Cassidy♦ | CC BY-SA 3.0 |