Mysterious NullReferenceException
-
Hi all, I have a very weird problem that i have been battling with (or pushing aside...) for months. I wrote an asp.net application that connects to an Oracle db using stored procedures. The procedures seem to work, the code seems to work and when I run it MOST of the time it runs great. But, sometimes (say 1 time out of 10 or 15) it crashes with the false accusation of a nullreference exception. If I go back and perform it again - it works. I added try/catch statements for this exception, and it has reduced their number (if I catch it and do nothing it works!!!), but it still happens and i'm pretty clueless on what to do. I suspect this might be some db problem, maybe i'm not closing connections right, but i don't know what it might be. Here are the 2 methods i use to access the database:
protected void execSQLsp(string newCommand, OracleParameter[] parr) { OracleDataReader dr = null; OracleCommand oraCommand = null; try { oraConn.Open(); oraCommand = new OracleCommand(newCommand, oraConn); oraCommand.CommandType = CommandType.StoredProcedure; if (parr != null) for (int i=0; i Second one handles cursor containing queries: `protected OracleDataReader execSQLcurr(string newCommand, OracleParameter[] parr) { OracleCommand oraCommand = null; OracleDataReader dr = null; try { oraConn.Open(); oraCommand = new OracleCommand(newCommand, oraConn); oraCommand.CommandType = CommandType.StoredProcedure; if (parr != null) for (int i=0; i` -
Hi all, I have a very weird problem that i have been battling with (or pushing aside...) for months. I wrote an asp.net application that connects to an Oracle db using stored procedures. The procedures seem to work, the code seems to work and when I run it MOST of the time it runs great. But, sometimes (say 1 time out of 10 or 15) it crashes with the false accusation of a nullreference exception. If I go back and perform it again - it works. I added try/catch statements for this exception, and it has reduced their number (if I catch it and do nothing it works!!!), but it still happens and i'm pretty clueless on what to do. I suspect this might be some db problem, maybe i'm not closing connections right, but i don't know what it might be. Here are the 2 methods i use to access the database:
protected void execSQLsp(string newCommand, OracleParameter[] parr) { OracleDataReader dr = null; OracleCommand oraCommand = null; try { oraConn.Open(); oraCommand = new OracleCommand(newCommand, oraConn); oraCommand.CommandType = CommandType.StoredProcedure; if (parr != null) for (int i=0; i Second one handles cursor containing queries: `protected OracleDataReader execSQLcurr(string newCommand, OracleParameter[] parr) { OracleCommand oraCommand = null; OracleDataReader dr = null; try { oraConn.Open(); oraCommand = new OracleCommand(newCommand, oraConn); oraCommand.CommandType = CommandType.StoredProcedure; if (parr != null) for (int i=0; i`I would think it indeed is a problem with the datareader. However - my limited experience in the field makes me say this with some restraints (I'm sure somebody more knowlegdable will come along and say I'm wrong anyway :D) As far as I understand it datareaders keep connection to the database, and if you fail to close them proberly, you could end up with one reader blocking another reader, in which case you get a timeout and get a nothing reader, which would give you your nullreference when trying to use this. I would suspect it might be the latter of your two methods where you return "dr". Personall - I'd rewrite the method so it doens't return a datareader, but instead wrap it into a DataSet and then return that. However - that is how I'd start debugging this error, but again - I'm limited in experience (I've only programmed professional and asp.net for 10months). --------------------------- 127.0.0.1 - Sweet 127.0.0.1
-
Hi all, I have a very weird problem that i have been battling with (or pushing aside...) for months. I wrote an asp.net application that connects to an Oracle db using stored procedures. The procedures seem to work, the code seems to work and when I run it MOST of the time it runs great. But, sometimes (say 1 time out of 10 or 15) it crashes with the false accusation of a nullreference exception. If I go back and perform it again - it works. I added try/catch statements for this exception, and it has reduced their number (if I catch it and do nothing it works!!!), but it still happens and i'm pretty clueless on what to do. I suspect this might be some db problem, maybe i'm not closing connections right, but i don't know what it might be. Here are the 2 methods i use to access the database:
protected void execSQLsp(string newCommand, OracleParameter[] parr) { OracleDataReader dr = null; OracleCommand oraCommand = null; try { oraConn.Open(); oraCommand = new OracleCommand(newCommand, oraConn); oraCommand.CommandType = CommandType.StoredProcedure; if (parr != null) for (int i=0; i Second one handles cursor containing queries: `protected OracleDataReader execSQLcurr(string newCommand, OracleParameter[] parr) { OracleCommand oraCommand = null; OracleDataReader dr = null; try { oraConn.Open(); oraCommand = new OracleCommand(newCommand, oraConn); oraCommand.CommandType = CommandType.StoredProcedure; if (parr != null) for (int i=0; i`if you remove the try catches on what line does it say the error is?
-
if you remove the try catches on what line does it say the error is?
If I remove the try/catch it fails when I try to execute the query.
-
I would think it indeed is a problem with the datareader. However - my limited experience in the field makes me say this with some restraints (I'm sure somebody more knowlegdable will come along and say I'm wrong anyway :D) As far as I understand it datareaders keep connection to the database, and if you fail to close them proberly, you could end up with one reader blocking another reader, in which case you get a timeout and get a nothing reader, which would give you your nullreference when trying to use this. I would suspect it might be the latter of your two methods where you return "dr". Personall - I'd rewrite the method so it doens't return a datareader, but instead wrap it into a DataSet and then return that. However - that is how I'd start debugging this error, but again - I'm limited in experience (I've only programmed professional and asp.net for 10months). --------------------------- 127.0.0.1 - Sweet 127.0.0.1
Hey, Thanks for the reply. So you think it's best to close the datareader as soon as possible? Basically, I close the datareader write after that procedure (after transfering data to a sortedlist) by executing the following:
dr.Close(); dr.Dispose(); dr = null; if (oraConn.State != ConnectionState.Closed) oraConn.Close(); -
Hey, Thanks for the reply. So you think it's best to close the datareader as soon as possible? Basically, I close the datareader write after that procedure (after transfering data to a sortedlist) by executing the following:
dr.Close(); dr.Dispose(); dr = null; if (oraConn.State != ConnectionState.Closed) oraConn.Close();It is always best to close the datareader as soon as possible, from what I've experienced and read. Update datareaders lock the data it access, which could deadlock with you trying to read from it if either reader is open "to long". A method to try and debug this possiblity would be to instead of acutally returning the datareader, then try to return some "dummy" data, and close the datareader in the same method. Then try to run the program X number of times to see if this helps on the issue. Also - I don't know if you have access to the database, but you could try to look at how many open connections there is during run-time, to see if the number is higher then expected, which could hint at some readers being open "to long" or even not closed proberly. --------------------------- 127.0.0.1 - Sweet 127.0.0.1
-
It is always best to close the datareader as soon as possible, from what I've experienced and read. Update datareaders lock the data it access, which could deadlock with you trying to read from it if either reader is open "to long". A method to try and debug this possiblity would be to instead of acutally returning the datareader, then try to return some "dummy" data, and close the datareader in the same method. Then try to run the program X number of times to see if this helps on the issue. Also - I don't know if you have access to the database, but you could try to look at how many open connections there is during run-time, to see if the number is higher then expected, which could hint at some readers being open "to long" or even not closed proberly. --------------------------- 127.0.0.1 - Sweet 127.0.0.1
OK, sounds like a way. Thanks for your help.