Debugging null data adapter
-
using C# and SQL Server 2005 Instantiate a data adapter on startup and re-use. No problems when 1 station running. When a number of stations running at the same time, data adapter goes null in the middle of the operation. i.e., It deletes some records from the database as it is supposed to do, but then goes null. Is there some way to query the database to get more information on why this is happening? Any debugging ideas? I don't have much experience with SQL Server, so if you have an idea please give me the specifics. Thanks.
-
using C# and SQL Server 2005 Instantiate a data adapter on startup and re-use. No problems when 1 station running. When a number of stations running at the same time, data adapter goes null in the middle of the operation. i.e., It deletes some records from the database as it is supposed to do, but then goes null. Is there some way to query the database to get more information on why this is happening? Any debugging ideas? I don't have much experience with SQL Server, so if you have an idea please give me the specifics. Thanks.
First, I didn't quite understand what you mean with 'station'. However, I believe that it's hard to observe this situation from database since the reason most likely isn't in the database. Instead, use debugger in Visual Studio, catch the exception immediately when it happens (use menu Debug/Exceptions... to catch all handled/unhandled exceptions) and then use breakpoints to narrow the area. The most likely cause for this is that if you are reusing same data adapter, when the first operation ends and you perhaps dispose the object, you use the same variable somewhere else (or same code in another thread) and the value is set to null. One way to get more information is to add diagnostics messages (for example using Trace.WriteLine) to every place where you instantiate the data adapter, set it to null (or dispose it, i.e. using blocks) or use it. This will give you info how things are going and in which order (especially if you're using threads). Hope this helps, Mika
The need to optimize rises from a bad design. My articles[^]
-
First, I didn't quite understand what you mean with 'station'. However, I believe that it's hard to observe this situation from database since the reason most likely isn't in the database. Instead, use debugger in Visual Studio, catch the exception immediately when it happens (use menu Debug/Exceptions... to catch all handled/unhandled exceptions) and then use breakpoints to narrow the area. The most likely cause for this is that if you are reusing same data adapter, when the first operation ends and you perhaps dispose the object, you use the same variable somewhere else (or same code in another thread) and the value is set to null. One way to get more information is to add diagnostics messages (for example using Trace.WriteLine) to every place where you instantiate the data adapter, set it to null (or dispose it, i.e. using blocks) or use it. This will give you info how things are going and in which order (especially if you're using threads). Hope this helps, Mika
The need to optimize rises from a bad design. My articles[^]
Thanks for the suggestions, Mika. By station I meant client. Via Debug/Exceptions is how null data adapter was determined. Adapter is instantiated on startup and disposed of when application quits - isolated in one class. Pretty simple in that respect. Agree it might be caused in some other area - since it happens sporadically and has been hard to pinpoint using the debugger, was just wanting to try another avenue. I was hoping the database might keep something like a 'last error' the way it tracks number of deadlocks. Have found a way around it for the time being. Thanks again ...
-
Thanks for the suggestions, Mika. By station I meant client. Via Debug/Exceptions is how null data adapter was determined. Adapter is instantiated on startup and disposed of when application quits - isolated in one class. Pretty simple in that respect. Agree it might be caused in some other area - since it happens sporadically and has been hard to pinpoint using the debugger, was just wanting to try another avenue. I was hoping the database might keep something like a 'last error' the way it tracks number of deadlocks. Have found a way around it for the time being. Thanks again ...
Okay, Just for explanation: If the command would fail while in the database or connection gets lost for some reason, you end up in an error at the database. As a result of an error you would get an exception at calling side (in C# in this case). So, if you're not receiving any exceptions in your code, but the data adapter just suddenly goes to null, it's quite certain that the problem is in the code. If you're using singleton or static class, perhaps one way to find out the problem is to define a property that returns your data adapter and keep the data adapter private in your class (if not already done so). Now in the property setter, first test if new value for the property is null and act based on that (throw an exception, write log etc). This could help you to isolate the cause. Also you could double-check that you are not ignoring any exceptions anywhere. One reason could be that the statement actually fails in the database, but you don't get information about the exception (for example an empty catch block). If you would end up in a deadlock you would get an exception in C# and have a message similar to:
"Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."However, if you suspect that deadlock might occur, you can set trace flag 1204 in startup parameters. After restarting the SQL Server, deadlock info if is written into errorlog at server side if a deadlock occurs. Hope this helps you forward, MikaThe need to optimize rises from a bad design. My articles[^]
-
using C# and SQL Server 2005 Instantiate a data adapter on startup and re-use. No problems when 1 station running. When a number of stations running at the same time, data adapter goes null in the middle of the operation. i.e., It deletes some records from the database as it is supposed to do, but then goes null. Is there some way to query the database to get more information on why this is happening? Any debugging ideas? I don't have much experience with SQL Server, so if you have an idea please give me the specifics. Thanks.
Look into threading problems (as Mika hinted). Other than that, we may need to see your code.
-
Okay, Just for explanation: If the command would fail while in the database or connection gets lost for some reason, you end up in an error at the database. As a result of an error you would get an exception at calling side (in C# in this case). So, if you're not receiving any exceptions in your code, but the data adapter just suddenly goes to null, it's quite certain that the problem is in the code. If you're using singleton or static class, perhaps one way to find out the problem is to define a property that returns your data adapter and keep the data adapter private in your class (if not already done so). Now in the property setter, first test if new value for the property is null and act based on that (throw an exception, write log etc). This could help you to isolate the cause. Also you could double-check that you are not ignoring any exceptions anywhere. One reason could be that the statement actually fails in the database, but you don't get information about the exception (for example an empty catch block). If you would end up in a deadlock you would get an exception in C# and have a message similar to:
"Transaction (Process ID 52) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."However, if you suspect that deadlock might occur, you can set trace flag 1204 in startup parameters. After restarting the SQL Server, deadlock info if is written into errorlog at server side if a deadlock occurs. Hope this helps you forward, MikaThe need to optimize rises from a bad design. My articles[^]
Thanks Mika, It is the last bit about the trace flag that I was looking for. Setting it I believe requires access to the server machine which I don't have, but the person who does says they can help me do this next week and he thinks he knows how to set a trace. Maybe more information than you are interested in, but since you put so much time in, don't want you to think I was ignoring your ideas. This was a situation of you have today to figure it out and then things are moving on and you need to be working on something else. Not to say it won't get revisited, but these are decisions made 'above' me. The null data adapter came about after code was introduced to allow for possible deadlock. It is most likely a case of interference/timing - something hasn't been thought through well enough for when multiple clients are running at the same time. Removing some functionality removed the deadlock problem and thus the need for the code that caused the null data adapter. Other people were looking into it from the C# side, and I was just asked to help if I could. I knew you could query the database for number of deadlocks and I had the permissions to do this. I thought if it was possible that the database could give any information, then it might at least be a clue for where to look. Now I will know about the database trace flag - it will come in handy at some point. Thanks.
-
Look into threading problems (as Mika hinted). Other than that, we may need to see your code.
PIEBALDconsult, Please see my response to Mika, and yes, if it gets revisted and I am involved in the revisit, I will look at the threading and try to get it narrowed down more. The code sits on an isolated system and is too complicated to reproduce here. The data adapter code is quite simple, but I think we're all agreed that that's probably just where another problem is manifesting itself. Thanks for your input.
-
Thanks Mika, It is the last bit about the trace flag that I was looking for. Setting it I believe requires access to the server machine which I don't have, but the person who does says they can help me do this next week and he thinks he knows how to set a trace. Maybe more information than you are interested in, but since you put so much time in, don't want you to think I was ignoring your ideas. This was a situation of you have today to figure it out and then things are moving on and you need to be working on something else. Not to say it won't get revisited, but these are decisions made 'above' me. The null data adapter came about after code was introduced to allow for possible deadlock. It is most likely a case of interference/timing - something hasn't been thought through well enough for when multiple clients are running at the same time. Removing some functionality removed the deadlock problem and thus the need for the code that caused the null data adapter. Other people were looking into it from the C# side, and I was just asked to help if I could. I knew you could query the database for number of deadlocks and I had the permissions to do this. I thought if it was possible that the database could give any information, then it might at least be a clue for where to look. Now I will know about the database trace flag - it will come in handy at some point. Thanks.
You're welcome :-D And I really appreciate that you took the time time answer. It's always good to know if a reply is helpful or not since we're all learning here :) If you need assistance in the future, post a message and we'll try to help you. Mika
The need to optimize rises from a bad design. My articles[^]