>>>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?
>>
>>No matter where the program files are stored - Novell, Server 2012 or local - the program itself is running on the local client. The SQL server should not be an issue because it's always accessed from the client machine, presumably using the same credentials.
>
>And that's the thing that has me puzzled -- if it was a rights issue with the network share, I'd usually see a completely different set of symptoms. What I'm seeing is an indication that there is either a problem connecting to or authenticating with SQL Server, as I'm seeing a SQL login dialog (but only when the application is launched from the share on the Windows fileserver).

Depends on the permissions issue :) Seriously, though, I can't see how there can be any problem with the SQL server or the local client's connection to it. In every case the program is running on the client, and connecting to the SQL server with (presumably) the same DSN and credentials. The Windows server should not be involved in that process at all. So, the question is how that server might be involved. The only idea I could think of was temp files.

>>Accessing a SQL server probably means creating temp files. Ideally those should always be on the local client but may not be the case for you. If temp files are being created on the same drive/share as the EXE then they would be created on the Windows server. If there are any permission issues for temp files that could "break" SQL operations. Can you test with admin privileges on the Windows share, if you haven't already?
>
>Thanks -- I'll have to check with the customer regarding access rights to application folder. I'll also have to check through command line to see where the TEMP and TMP environment variables are pointing (normally one would expect to have it reference a local folder).. In those cases where there was an access rights problem on network share, I usually see a different set of symptoms (e.g. cannot write to cursor). As stated previously, the behavior would seem to indicate a connection problem or problem with authenticating with SQL Server -- I'm seeing a SQL login dialog.

The Windows TMP/TEMP environment variables could be red herrings. I'd look at the temp file settings of VFP i.e.

TMPFILES= in CONFIG.FPW
SYS( 2023 )
Any other config files in play, maybe due to EXE command line switch(es)

Other left-field ideas:
- Non-existent folder(s) in SET PATH
- Resource file in use - SYS( 2005 ), permissions to resource file if in use
- Conditional branch in code that does different things if, say, SYS( 5 ) has different values
- Are the Windows server and local client both on a domain?
- Is networking configured properly? Any chance of funky DNS settings, connections to different hosts being made on IPv6 vs IPv4 etc.? Default protocol configured if Novell IPX/SPX still present on the network?