>>Good luck. I think on the machine where you put the SQL you only need to open port 1433 both ways (in and out) in the firewall settings. I did that on a few 2012 or 2016 servers (perhaps ever newer ones) when the customers had partially installed the SQL server, leaving everything on default. And we know this server is written by the world champion in the category of wrong defaults. Sometimes I think they add a feature only in order to annoy us, so we'd have to find where it's set (or more often tamed, disabled or just shot). So I sort of remember what the usual steps were: enable direct logins (default is to use windows/domain logins), change collation to that of the country (specially if the server is in Slovakia and the owners from Canada, they'd never remember to set this)... and then fiddle with the rest if annoying, this alone should be enough to make it work.
>
>After rethinking of what I am trying to do, your suggestion to "yank" the cable is not what I need. If I yank the cable, the SQL Server is down and of course the application will crash.

Well it shouldn't crash, it should just report that the server is inaccessible and offer to retry in a few seconds. But when it reconnects it should just finish what it was doing and move on. That's how I understood Walter's trick, it should cover those cases as well.

>I am trying to simulate the situation where the SQL Server is up and running nicely. But the application "falls asleep" and loses connection. Then the application tries to restore the connection.
>I will try to open the application and then wait for my PC to "fall asleep." Maybe this will create the situation I am looking for. Actually I am leaving in about an hour for about an hour and half. I will start the application and leave it on. I will see what happens when I come back.

In control panel, power settings, you can set the sleep interval to something shorter. Or you just wanted to take a break, citing "testing app going to sleep", eh? :).