DBNETLIB ConnectionOpen (Connect()) error with Delphi 2010 application accessing SQL Server 2005 with OLEDB drivers on Windows 7 x64

I built a D2010 application, which uses a TADOConnection component to connect to SQL Server using OLEDB drivers and tcp/ip. The开发者_如何学运维 problem is that my application can't connect to the database when I execute it (inside the IDE or not) from a network drive. Each time I try i get this error through the IDE:

---------------------------
Debugger Exception Notification
---------------------------
Project TroisTiers.exe raised exception class EOleException with message '[DBNETLIB][ConnectionOpen (Connect()).]SQL Server does not exist or access denied.'
---------------------------
Break   Continue   Help   
---------------------------

and I get a "EOleException: Unspecified error" when I run the application outside the IDE.

The thing is, When I copy the .exe on a local drive (C:) it works instantly, no errors, no lag. When I compile the D2010 application on a WinXP computer and execute it from Win7, it also works flawlessly. When I take the .exe I builded and execute it on a x86 Windows 7, I get the same errors as above.

I noticed that when I start the application on the network drive, the following modules are loading:

Module Load: WSHTCPIP.dll. No Debug Info. Base Address: $74CD0000. Process TroisTiers.exe (848)
Module Load: WSHIP6.dll. No Debug Info. Base Address: $74010000. Process TroisTiers.exe (848)
Module Load: DBnmpntw.dll. No Debug Info. Base Address: $750C0000. Process TroisTiers.exe (848)

I have asserted that the app tries to connect using TCP/IP first, then for whatever reason resorts to named pipes. Just for tests, I activated the named pipes protocol on the server and it started to work but not every time and takes up to 10 seconds before the connection is made. I deactivated it since it's not the way we connect to the production databases. When the app is executed locally (and showing data correctly), the DBnmpntw.dll module is neved loaded.

When I build a connection string (through a .udl file) and test the connection, it works, though I am not certain if I'm testing through the 64bit or 32bit drivers.

Setting the .exe output directory to my local drive is an acceptable work-around for now but I would really like to know what's causing this problem, as it makes things complicated with working in an up-to-date environment (additionnal files beside the .exe).

Additionnal info, for what it's worth:

My connection string: 'Provider=SQLOLEDB.1;Persist Security Info=True;User ID=*;Password=hunter2;Initial Catalog=[database name];Data Source=[server ip address]'.

I tried to force using TCP/IP with "Network Library=DBMSSOCN;" but it doesn't help.

Firewalls disabled on my computer and on the server;

McAfee AV on my computer, managed through ePO;

SQL Server 2005 x64 running on Win2k3 x64;

Windows 7 without SP1 installed;

cliconfg.exe -> active protocol is tcp/ip only;

I can provide additionnal info if needed.

Is your .EXE too large for running on a network shared drive? I have the same experience when the size of .EXE exceed 25MB or something closed to.

The solution is simple, just to move the .EXE back to local drive.