>>From the ClearAllPools() reference: "ClearAllPools resets (or empties) the connection pool. If there are connections in use at the time of the call, they are marked appropriately and will be discarded (instead of being returned to the pool) when Close is called on them."
>>
>>IOW if other processes have connections open, that call does not force them closed - and rightfully so IMHO.
>
>Yes, that is exactly why I need a brut force completion of everything in memory.
>
>>Also, I'd think if that call is supposed to be global (and I'm not sure it is, it might be limited to the calling process's security context) then you might have to run with elevated privileges.
>
>Yes, that is correct.
>
>>If you haven't already, you might want to run the connection enumeration code in the link I posted earlier to make 1,000% sure there aren't other unexpected processes with open connections.
>
>That is the only one. Once the data adapter fill executes, it keeps something in memory towards SQL Server. If I comment that line, I can restore. If that line executes, I cannot. So, there does not seem to be a way to close all connections from a remote perspective. However, from reading at several pages, some seems to rely on that command to achieve this.

Documentation states that if the connection is not open when Fill() is called (which should be the case here) then the connection is automatically opened and *automatically closed* when the Fill() completes.

Where does this ensure that the DataAdapter is actually using loSQLConnection ?

Using loSQLConnection As New SqlConnection(oApp.aConnection(nConnectionString, 1))
   oCommand.Connection = loSQLConnection
   oDataAdapter.Fill(oDataSet)
End Using