[EarlyMorningRiser]

Hi All,

This is my first plea for help and boy do I need it .

Here are the basics:

• C# 2.0
  
• Windows Application, deployed via Click Once (or click 4 times, depending on how you look at it ).
  
• Connects to SQL Server 2000 using typed datasets
  
• This is a business application that displays data in Infragistics UltraWinGrids 7.3 and allows the user to Insert/Update/Delete within those grids.

_

The application normally works just fine, but from time to time it will simply stop responding – requiring the user to use task manager to “end task” on the application.

I’ve been able to duplicate this “freezing” of the application on a few machines (usually a server that I have access to via a VM session) by opening the app and then walking away from it for a few hours. Half the time, when I return, the application has stopped responding.

Things I’ve done to trouble shoot:

• Duplicate the bug on a machine and then check the Application Logs for errors. No errors are listed for my application.
  
• I’ve tried to duplicate the lockup within Visual Studio 2005 in Debug mode, but the application does not lockup there.

_

Things I’ve assumed:

• I’ve used the same Infragistics controls heavily in other windows applications with no issues; so I do not believe they are the issue.
  
• The freezing does not occur during a database request; so I’ve ruled that out.
  
• I’m using BackgroundWorker to perform a single task asynchronously, but that task finishes before the freezing occurs; therefore I’ve ruled out BackgroundWorker being the culprit. Just to be sure, I call BackgroundWorker.Dispose() within the RunWorkerCompleted event.

_

Does anyone have any additional debugging tips that I could use?

Thanks!

-EMR

[PsychoCoder]

Well if it happens after long periods of inactivity then more than likely your connection to your SQL Server has timed out. You have 2 options, use a timer than checks the State Property of your SQL connection and reconnects if need be.

Use Application.DoEvents so other processes do not have to wait for your timer, or you could also run it in its own thread. If the State of the connection is closed then reopen the connection. This just may stop some of your hanging after long periods of inactivity

[EarlyMorningRiser]

PsychoCoder, on 3 Jan, 2008 - 11:28 AM, said:

Well if it happens after long periods of inactivity then more than likely your connection to your SQL Server has timed out. You have 2 options, use a timer than checks the State Property of your SQL connection and reconnects if need be.

Use Application.DoEvents so other processes do not have to wait for your timer, or you could also run it in its own thread. If the State of the connection is closed then reopen the connection. This just may stop some of your hanging after long periods of inactivity

Hmmm, to tell you the truth, except for one or two connections, I'm not managing the connection whatsoever - though even those rare connections are being handled through Microsoft Data Access Application Block's SQLHelper class.

For example, when filling a particular grid, I do the following. I assumed the .Net 2.0 framework handled the connection for me. Would that be a correct assumption?

		private void Grid_LoadStatusSummary()
		{		  
			  _statusSummaryTA1.Fill(_reports1.StatusSummary);
			  gridStatusSummary.DataSource = _reports1; 
		}

[PsychoCoder]

Theres nothing in the Framework that keeps a connection open during inactivity. If theres no database activity the database server will disconnect you, so before doing any DB work check the state of the connection

[tody4me]

[rant]
I never let the framework handle the connection thru the use of the dataadapter. The whole point of using the connection in that way is to be disconnected from it. If you want to manage the connection yourself, do so, otherwise use it in the disconnected state that Microsoft wants you to use... and don't whine about it being disconnected.
[/rant]
If you control it yourself, it's a lot more steps with the .NET framework. You can use a connection object, and command objects separately from the Dataadpter and Dataset built in features. If you want to leave the connection open, you can do so for the duration of the scope of the variable. Personally I never use the dataadapter and datasets in my applications.
Psycho is right about the server disconnecting you if there is inactivity, but if the connection is active within 30 seconds you are dealing with the data in a live state.

This post has been edited by tody4me: 03 January 2008 - 02:06 PM

[EarlyMorningRiser]

tody4me, on 3 Jan, 2008 - 02:03 PM, said:

[rant]
I never let the framework handle the connection thru the use of the dataadapter. The whole point of using the connection in that way is to be disconnected from it. If you want to manage the connection yourself, do so, otherwise use it in the disconnected state that Microsoft wants you to use... and don't whine about it being disconnected.
[/rant]
If you control it yourself, it's a lot more steps with the .NET framework. You can use a connection object, and command objects separately from the Dataadpter and Dataset built in features. If you want to leave the connection open, you can do so for the duration of the scope of the variable. Personally I never use the dataadapter and datasets in my applications.
Psycho is right about the server disconnecting you if there is inactivity, but if the connection is active within 30 seconds you are dealing with the data in a live state.

Ah, based upon your rant ( ) and since I'm not taking any additional steps to modify the code generated by the tableadapter when its plopped within the ".xsd", I'm handling my datasets in a disconnected state - i.e. grabbing the data and disconnecting for each and every database call. Therefore I shouldn't be having issues with my connection being disconnected due to inactivity. Right?

[tody4me]

correct.

This post has been edited by tody4me: 04 January 2008 - 08:33 AM

[EarlyMorningRiser]

tody4me, on 4 Jan, 2008 - 08:33 AM, said:

correct.

So if the connection isn't causing the lock up, I guess it could be the BackgroundWorker that is causing the problem.

Has anyone else experienced issues with BackgroundWorker? I've used it in other applications, but have not had this freezing issue before.

-EMR

[killnine]

EarlyMorningRiser, on 8 Jan, 2008 - 01:53 PM, said:

tody4me, on 4 Jan, 2008 - 08:33 AM, said:

correct.

So if the connection isn't causing the lock up, I guess it could be the BackgroundWorker that is causing the problem.

Has anyone else experienced issues with BackgroundWorker? I've used it in other applications, but have not had this freezing issue before.

-EMR

Why would the background worker cause your whole app to freeze? That's the reason I use background workers, because they separate a work thread from the UI, keeping the UI from locking up. The symptoms you describe make me hesitant to say its a BW issue.

[EarlyMorningRiser]

killnine, on 11 Jan, 2008 - 08:44 AM, said:

Why would the background worker cause your whole app to freeze? That's the reason I use background workers, because they separate a work thread from the UI, keeping the UI from locking up. The symptoms you describe make me hesitant to say its a BW issue.

Since my last post, I pulled the function calls out of the BW and now call them within my form's load event. Even though I'm using the exact same code, the freezing issue has not happened again (to my knowledge to date). Since the execution time is only 5 or so seconds, the client is okay with the change.

I do not know why the freezing issue no longer occurs without the BW for this particualr implementation, but I plan to continue making use of BW in other places and applications.