You have only a limited number of approaches to ensure the safety and security of your connection string.
One option is if your connection string is stored in the web.config or app.config file (for web and Windows applications, respectively), you can encrypt the value. Here are some links that detail how to do this:
Web.Config value encryption in ASP.NET 2.0
Encrypt connection strings in .config VS 2005 files. Files
Of course, as you rightly say, this may not provide the required security, since the application may well run on the user's computer and, therefore, the app.config file (even in an encrypted state) and the associated encryption / decryption keys will also be available on custom car. A knowledgeable and adventurous user can then access your "plain-text" line.
IMHO, one of the best ways to prevent your users from seeing your database connection string is to never pass them to them, primarily encrypted or not. This will require that your Windows Forms application not speak directly to the database (using the connection string), but rather speak directly (for example) to the web service.
Of course, you must provide the Windows form application with a URL with which it can access the web service, but then the use of this web service will be limited and controlled only by allowing access with a custom username and password combination.
This way you can host a web service (not necessarily a web service — it could be a remote application that your window-making application will contact with .NET remoting or WCF ) on a physically separate server / machine that you are running , has a complete control and protection of this device with perimeter protection .
These will be applications and services that you have running on this protected machine that have access to the database connection string, and this connection string should never be divulged outside the perimeter of this machine, thereby fully protecting it (provided that the aforementioned perimeter security is in place and effective).
Of course, implementing all of this would almost certainly mean huge architectural changes for your application, which, depending on the size and nature of your application, may or may not be useful, however, the only way to really protect your connection string from the user (or the user machine) must ensure that it will never be available (in encrypted or decrypted form) for the user (or user machine).
As soon as you put the connection string on the user machine, even in an encrypted state, you need to provide the same computer that is able to decrypt this encrypted connection string, and there is a weak link in the chain and a point on which (for the resourceful user) you can determine the connection string with plain text. You can disable decryption of the encrypted connection string on another (secure) machine, but this is just an option of the client-server mechanism mentioned earlier, in which the protected part (decryption key, connection string, etc.) is saved on another machine under your own secure control.