>>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.

One way you could brute force connections closed is to call an appropriate sproc on the SQL Server itself rather than trying to do it from a client application. Assuming your SQL login/role has enough privileges, the SQL Server process can close existing connections (you may need to set it to reject new ones just prior to closing existing ones). Once again, the link I posted earlier shows how to do this (not tested by me). The reason the author created that post: "Many a times it becomes impossible to find out the active connections to a SQL Server database. That could create a lot of irritation while doing database activities like restoring a database. Below is the code that will show you the active connections to a database."

https://www.codeproject.com/Articles/389725/How-to-find-the-active-SQL-connections-and-kill-th