>Just ran into a head-scratcher at customer site. We've got a VFP application that connects to a MS-SQL server. Program had been working fine when the program files were hosted on a Novell file Server. After migrating the application folder to a Server 2012 fileserver in a shared folder, it stopped working -- the error suggests that the application cannot connect to SQL Server -- either that connection couldn't be established, or if authentication with SQL server is failing. If we copy the application folder to a local drive then run the program from local drive, the program starts working -- there have been no other changes made. The SQL Server was installed to work with SQL Authentication, and the DSN has been configured accordingly -- test within ODBCAD32 (the one in the SysWow64 folder) indicates the DSN definition is OK. In short, the program works fine program files are hosted on Novell or local drive, but not when hosted on Windows file server. Any ideas of what might be happening?

Some info that I'd neglected to mention:
* After some delay after attempting connection (either explicitly through SQLSTRINGCONNECT() and implicitly through a DBC), a SQL signon dialog comes up.
* The CONFIG.FPW is built into the EXE, and it doesn't explicitly specify an TEMPFILES (so I'd assume that the regular temporary folder will get used, as I'd seen in most cases).
* In the built-in CONFIG.FPW there is a RESOURCE=OFF, so I'd assume a VFP resource file isn't going to be involved (as far as I've seen, none is auto-generated).
* There was an indication that there might've been a problem with the configuration of the share -- I did ask about the permissions assigned to the application folder, and was told user had effective rights of "full control" -- however behavior would indicate folder was read-only -- pointing at the possible problem where Security and Sharing weren't configured the same way (e.g. if in Security you grant write access, but if you don't grant it through sharing also, you'd effectively not have write access when accessing the share through the network, but you would have write access if you were logged in locally on the network).