>>Assuming you've fired up the form using Application.Run(new WhateverForm()) then using WhateverForm.Close() to exit should be best.
>>But you mention a 'database flag' so what does your button click handler actually do ?
>>Are the tasks you speak of running in the same form ? Same thread ?
>>Is the forms OnClosing() and OnClosed() being called ?
>>If so does is the Application.ThreadExit event firing ?
>>IAC enabling JIT debugging is probably the way forward.........
>
>The EXE is only one form. So, the startup form is Main, which is Main.vb. This is single threaded. There is only one instance in memory. To stop it, we can do it from the interface by the close button, which never causes the problem BTW. Or, from the Web interface, I can change a field value in a table before every loop to see if it has to close. If the field is False, the robot will close by itself by simply calling CloseForm(), which only contains one line which is Close(). This is when we can have the problem. This happens from time to time.
>
>So, this is why I pointed out the number of method levels down because when I close from the interface, we do not have the problem. But, when it is being closed from a call which is fired from several methods down, sometimes, we have the problem.
>
>Here is the code to detect if it has to close by itself:
>
>

>        ' expO1 Data provider
>        Private Function ProcessTaskQuery(ByVal toDataProvider As Framework.Data) As Boolean
>            Dim lnCounter As Integer = 0
>            Dim loDataProvider As Framework.Data = New Framework.Data(oApp)
>            Dim loRow As DataRow = Nothing
>            Dim loUpdate As Framework.Update = New Framework.Update(oApp)
>
>            ' We have to get the primary key of the server to know if it is running
>            loDataProvider.ParameterAdd("Numero", nRobotPrimaryKey, , "Robot", "Numero")
>            If Not loDataProvider.SQLExec("SELECT Robot.NoServer,Robot.Run " + _
>             "FROM Robot " + _
>             "WHERE Robot.Numero=" + loDataProvider.ParameterAddSQL("Numero")) Then
>                Return False
>            End If
>
>            loRow = loDataProvider.oDataView(0).Row
>
>            ' If the robot server and Run do not match
>            If oApp.nNoServer <> loRow("NoServer") Or Not loRow("Run") Then
>
>                ' Reset the parameter on the robot
>                loUpdate.cAlias = "Robot"
>                loUpdate.nPrimaryKey = nRobotPrimaryKey
>                loUpdate.ParameterAdd("Loop", 0)
>                loUpdate.ParameterAdd("Version", "")
>                If Not loUpdate.Update() Then
>                    Return False
>                End If
>
>                CloseForm()
>            End If
>

>
>Basically, what is of interest to us here is the Or Not loRow("Run"). This is the flag. So, if the Robot.Run field is False, it indicates to the robot application to close. Before doing it, I update a few fields in the table. But, this is not a factor. The next line calls CloseForm().
>
>Here is the CloseForm() method:
>
>

>        Public Sub CloseForm()
>            Close()
>        End Sub
>

>
>So, based on the fact that this project is only one Main.vb form, which is the startup form to run from the Project Properties, is Application.Exit() better?
>
>Do you also think that I should move up the hierarchy CloseForm()? So, instead of executing it here, do you think I should simply return to the calling method, to the other one and to the master one and indication that CloseForm() should be called from there instead?

I don't think that the level at which CloseForm() is called should be a problem. But it does seem as if you are calling the CloseForm() whilst the SQL connection is still open? It may not be the cause of the problem but it would certainly be better practice to ensure that it is closed before the routine exits........