Please forgive the lengthy post, but this really is the short version – honest...
A couple of weeks ago we moved our oracle databases from a Windows 2003 server to a Windows 2008 server and upgraded them from 32 bit processing to 64 bit processing. The transition has been perfect with all our applications except in one case.
We have a web app, developed with .net 2003 several years ago, that has had a recurring error we have suspected to be caused by corrupted cache, session variables or application variables. Prior to the database move (and subsequent server upgrade) the error only occurred once every 2 to 3 weeks. The accepted "fix" was to just restart the application pool and all would be well for another 2 to 3 weeks (yes, we know – not cool, but those folks aren't here anymore). However, once the application began being used after the database move, it started happening 3 or 4 times a day and it almost seems to be getting worse.
How it starts is that one or two of the end users will get an error message indicating "index out of range" or "object not set to an instance of an object" – they are in the same process/page of the application (because this is the time of day that this process is accomplished across the contract), but they all bomb out on different lines. So they close the app/browser and go back in, they may be able to work for a bit longer but then will get a similar error again. Eventually all of the users (about 6 at a time) will begin receiving the same errors and no one can do anything – then we restart the app pool and everything's okay for a while. Again, previously this was fine and gave us a few more weeks before we saw it again, but now we're lucky to get 20 more minutes out of it.
I know this is an issue that needs to be addressed in the code itself, but it's painfully obvious that something to do with the moving the databases to a 2008 server or to 64 bit processing has had an effect on this application and escalated this error that was once tolerable to bringing the application to its knees.
Anyone have any ideas? I'm hoping that someone else has experienced something similar after moving to or upgrading a server and may be able to point us in the right direction so that we can at least get the application back in a useable state on a more consistent basis for the end users.
(previoulsy posted in VB.NET 2002-2008 Forum, thanks to RiverGuy for directing me to this forum)
Becky,
Ft. Rucker
A couple of weeks ago we moved our oracle databases from a Windows 2003 server to a Windows 2008 server and upgraded them from 32 bit processing to 64 bit processing. The transition has been perfect with all our applications except in one case.
We have a web app, developed with .net 2003 several years ago, that has had a recurring error we have suspected to be caused by corrupted cache, session variables or application variables. Prior to the database move (and subsequent server upgrade) the error only occurred once every 2 to 3 weeks. The accepted "fix" was to just restart the application pool and all would be well for another 2 to 3 weeks (yes, we know – not cool, but those folks aren't here anymore). However, once the application began being used after the database move, it started happening 3 or 4 times a day and it almost seems to be getting worse.
How it starts is that one or two of the end users will get an error message indicating "index out of range" or "object not set to an instance of an object" – they are in the same process/page of the application (because this is the time of day that this process is accomplished across the contract), but they all bomb out on different lines. So they close the app/browser and go back in, they may be able to work for a bit longer but then will get a similar error again. Eventually all of the users (about 6 at a time) will begin receiving the same errors and no one can do anything – then we restart the app pool and everything's okay for a while. Again, previously this was fine and gave us a few more weeks before we saw it again, but now we're lucky to get 20 more minutes out of it.
I know this is an issue that needs to be addressed in the code itself, but it's painfully obvious that something to do with the moving the databases to a 2008 server or to 64 bit processing has had an effect on this application and escalated this error that was once tolerable to bringing the application to its knees.
Anyone have any ideas? I'm hoping that someone else has experienced something similar after moving to or upgrading a server and may be able to point us in the right direction so that we can at least get the application back in a useable state on a more consistent basis for the end users.
(previoulsy posted in VB.NET 2002-2008 Forum, thanks to RiverGuy for directing me to this forum)
Becky,
Ft. Rucker