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.