>>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
>
>It is within a control environment. I am the one using the application. I need some processes to be done when the application starts and also for the ongoing process. But, when comes time to restore, I need to be able to do it from that application assuring the active connections would drop.
>
>What you mention seems to be pretty much what I should consider.

It is brute force and not elegant. If you know a command you're issuing is causing the problem, one would like to think it would be possible to "clean up after oneself" rather than relying on brute force.

Are there any additional parameters to your data fill command such as CloseConnectionWhenDone? What about the connection you're using for that - anything like DontPoolThisConnection, or manual connection handling that would prevent pooling? Are you making new connections (even if they're pooled) for each operation or are you using a global connection which has been defined higher in the call stack?