1

Execution of .Net Console EXE always fails with below error, this happens only when EXE placed on network drive, from local system it works without any connection error.

A network-related or instance-specific error occurred while establishing a connection to SQL Server. The server was not found or was not accessible. Verify that the instance name is correct and that SQL Server is configured to allow remote connections. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified).

Any assistance will be appreciated.

Joel Coehoorn
  • 399,467
  • 113
  • 570
  • 794
Hi10
  • 531
  • 1
  • 5
  • 21
  • Try to enable remote connections in SQL Server. Open SQL Server Management Studio -> right click the server -> properties -> Connections -> ensure that Allow remote connections to this server is checked – I.Manev Feb 15 '18 at 15:45
  • @I.Manev this setting exists. – Hi10 Feb 15 '18 at 15:47
  • How about this: SQL Server Configuration Manager -> SQL Server Network Configuration -> Protocols for MSSQLServer -> TCP/IP should be Enabled – I.Manev Feb 15 '18 at 15:47
  • @I.Manev that too exists, and no issues with management studio or executing EXE from local drive, but when schedule task execute the same exe it fails with SqlConenction error. – Hi10 Feb 15 '18 at 15:51
  • Are you sure that the connection string is correct and the firewall doesn't block the connection ? Create new rule for the port that you are using if you are not sure about it Windows Firewall with Advanced Security -> Inboud Rules -> New Rule. – I.Manev Feb 15 '18 at 15:57
  • 100% @I.Manev, no issue if same EXE ran from local drive, as soon as placed on network drive, SQL instance could not be found. – Hi10 Feb 15 '18 at 16:23
  • Make sure that network drive is on a server that is listed as a secure site in your internet options, otherwise it will run with partial or no trust and not be allowed to do much. – Lasse V. Karlsen Feb 15 '18 at 16:30

2 Answers2

1

The issue found with “missing permission at top directories in path hierarchy”. After providing appropriate permission to top directories, EXE was able to connect SqlServer. It appears that in absence of such permission security policy restricts application to access network resources.

Hi10
  • 531
  • 1
  • 5
  • 21
0

Ok the key is you said "when schedule task execute the same exe it fails with SqlConenction error". If you are running this task under the Windows Scheduler, make sure the Windows Scheduled job is running with the correct credentials. By default they run under Windows Service which wont have rights to connect to the SQL Server. Set the Windows Schedule task up with a specific account name and password.

PhillipH
  • 6,182
  • 1
  • 15
  • 25
  • Schedule process is running under dedicated service account(ad account) and it has sufficient permission, if exe placed on local file system no problem. But exe should reside on network storage. – Hi10 Feb 15 '18 at 18:52
  • Is this .net Framework 3.5 SP1 and above, or lower ? Before 3.5 SP1 you couldn't execute .net assemblies on a network share without CASPOL. (https://stackoverflow.com/questions/148879/why-does-my-net-application-crash-when-run-from-a-network-drive) .net 4.0 seems to have interfered with this ability as well. To clarify - if you excute the program interactively (under your account) on C: it works, but not if on network share ? Where is the connection string being read from ? If in config file, where is that located ? – PhillipH Feb 15 '18 at 21:30
  • Exe is console App, created with .Net 4.6 framework, run-time is 4.0. – Hi10 Feb 16 '18 at 14:19
  • @Hi10 - ok, thats the first part of my question covered; but To clarify - if you excute the program interactively (under your account) on C: it works, but not if on network share ? Where is the connection string being read from ? If in config file, where is that located ? – PhillipH Feb 16 '18 at 21:23
  • yes on local drive exe run with no problem, it is reading connection from its config, exe and config both are in same folder. – Hi10 Feb 17 '18 at 03:30