Dear TariqMemhmod.
Actually, the clean solution is to let clients close their connections with SQLDisconnect(). Whenever you'd cut off a server via disabling the network adapter or stopping the SQL Server service or disconnect just the connections to a specific database when putting it offline or in single-user mode, that is a disruption. Applications will throw errors when you do that, users end up with unsaved changes, not able to end tasks if you do that during business hours.
Be assured, I don't assume you'd do, you'd likely want to do all that after hours. But in today's world, admins don't sit at servers themselves to maintain them, not on the software level, you set them up for remote handling and then you obviously never diable adapters.
And as I already said you also don't need to disconnect users to do almost any task on SQL Server, including backups and database updates. I don't even know why anybody would want to do that aside from retiring a server. Or for hardware maintenance. And then you can even make it simpler to yourself, shut down the server. Do your hardware maintenance and turn it on again. Or if there is software maintenance you can only do offline. Then simply turn off the Wi-Fi router, remove cables and turn the server on, you'll be able to work on whatever and eventually turn it off again, bring back the ethernet cabling or Wi-Fi or both finally bring back the server.
So far I could only think you want this features to be embedded in your client-side application, but once you want to do administrative things, there are already all kinds of Windows out-of-the-box solutions, even if you want to automate some things done in one go, write Powershell or batch scripts for that, don't write an admin VFP EXE or PRG. If you're doing admin work and want to automate it, that's the domain of batch scripts and not VFP and I bet you find ready to use solutions in forums about server administration. Don't use VFP as your admin tool for tasks not about VFP.
Bye, Olaf.
Olaf Doschke Software Engineering