I would recommend to use an application launcher. See file #21770, for example.

>I have had several clients with Windows 7 that are reporting problems connecting from a VFP 9 application to their SQL Server if the VFP application is run from a network share and it is an EXE file.
>
>I am using a DSN-less connection to the SQL Server where I specify the Static IP address and static port number.
>
>My test server where I have been able to duplicate this behavior and where both the network share and the SQL Server are installed is a Windows 2008 SBS server with SQL Server 2005 Express.
>
>I am using SQL Authentication (not Windows Authentication) for the login so it is not a matter of “trust”.
>And the error is below which really indicates it cannot even find the SQL Server. However the same exact connection information when used from a local folder on the same computer works fine so it is not the connection information or a firewall issue.
>
>Connection failed
>SQL State '01000'
>SQL Server error 53
>[Microsoft][ODBC SQL Server Driver][DBNETLIB]Connection Open
>Connection failed
>SQL State '08001
>SQL Error 17
>[Microsoft][ODBC SQL Server Driver][DBNETLIB]SQL Server does not exist or access denied.
>
>It only fails to connect to the SQL Server if ALL of these are true:
>- Windows 7 (Works fine with Windows XP.)
>- Application running on network share. (Works fine run from a local folder)
>- The user account cannot be an administrator. (Works fine if run as an Admin)
>- The FoxPro program is an EXE file and not an APP file
>
>It with SUCCEED if I do ANY of these:
>- Use Windows XP. (This was discovered as my customer started updating/replacing their XP computers with Windows 7 computers.)
>- Copy the entire network share folder to C:\Temp and run it from there. This is the temporary workaround they are using.
>- The program is started by someone with Windows Admin level rights or by using the Run as Admin… feature.
>- From the VFP development environment I can run an APP version and it will work fine. It is only running an EXE (which in-turn calls an APP) that there is a problem. Unfortunately the customers all have just the FoxPro Runtime and cannot run the APP files directly.
>- Although this might be a red herring… I noticed that if I stop and restart the SQL Server service there is a pretty good chance that I will be able to connect once or twice in the questionable configuration before it start failing all the time again and I have to go back to the local drive solution.
>
>So the problem is tied to some behavior specific to an EXE run from the network share that was introduced in Windows 7 (or maybe in Vista). I have tried every security setting I can think of both with the folder and file as well as adding the network folder to Trusted Sites and reducing the security setting there.
>
>Unfortunately running off a local drive is problematic since the software is normally only updated once in the shared folder and if each user has their own local copy they need to update a lot of individual copies. (I have over 10,000 users.) I can write a program to compare the local copies of the files to the set in the network share, although I am hoping for a better explanation/solution.
>
>Any ideas or suggestions would be appreciated.
>
>I have spent considerable time on Google and UT and found very little information on this.