I spoke about this in a previous question, but I have since narrowed down the issue to make it possible to be answered. First, some background.
I have an ASP.net website that functions normally on the local server, but when it’s on the live server and accessed externally, it has some session data issues that make occasionally throw errors. The first issue turned out to be an problem with IE9. The session variable just wouldn’t persist after it reached the second page and hit the stored procedure. I fixed this by foring the page to run in IE7 mode with –
This still occurs on some browsers (specifically it occurs -once- with firefox) but I created a loop that forces it back to the menu page when the session variable is blank so it just appears as the page didn’t load and the “open” button can be pressed again.
However, the new problem happens when I attempt to save the data on a form. It passes a few session variables in to the stored procedure interface (like staff ID and such) and what appears to happen is that it times out. However, all of the timeouts for the session set in webconfig and IIS are extremely high numbers (many hours) and the worker processes are set to never expire or recycle. Also, it happens even after a minute or two so it can’t be the timeout hitting. It’s just like it randomly loses the session values. The weird thing is that if you go back and save again – performing the same actions with the same data – it tends to work. Sometimes it takes a few iterations of this but ultimately it will work.
The strange thing is also that it tends to randomly lose pieces of the viewstate – such as field values – but that might be unrelated and have more to do with the fields that are filled automatically at load. But I thought I’d include that in case it offers and information as to why it might be doing this.
I’m considering a workaround by dumping the session variables in to viewstate variables as soon as the page loads, but I’d really like to address the problem directly so I don’t have to deal with it in the future when I can’t do something like that. Is there some poriton of IIS (It is IIS 6 by the way) that could be the culprit? Are session variables just known for dying when being thrown around a lot? I can’t say I know a great deal about server set up but I’ve learned a lot from this situation and beating this will be a wonderful victory for my morale. Thank you for reading and sorry it’ so long!
I actually found the real solution this time around. It still doesn’t make a lot of sense but I thought I’d bring it here just for everyone to see. It turns out, one of the dates that was being pulled from a table was being stored in the session variable as a blank (even though it shouldn’t have been) and then somehow, even though there was an if statement that should have prevented it, it tried to convert the blank string of the session to a date. Certainly strange. It was as if the session had a value when reaching the if statement and then after it checked it against the criteria, it changed it to a blank string and threw the error.
So it turns out it wasn’t really a session issue, just a strange date issue. It was only occuring with one person and one particular date from the table. I fixed it by simply putting a try-catch around it. Everything has been working fine for that individual since then. Thanks again for the help everyone!