Related
I can't seem to connect to my database from a site. I get this error:
Named Pipes Provider, error: 40 - Could not open a connection to SQL Server
I tried using the local IP address to connect as well as a public one. I've tried:
Yes, the site can communicate with the server
Named pipes/TCP is enabled.
Remote connections are allowed.
Windows Firewall is off
Created an exception for port 1433 in Windows Firewall.
Enabled everything in SQL Server Configuration Manager.
What else can I do here?
Solving this problem is very easy:
Go to control panel.
search for services.
Open Local services window from your search results
Restart your MSSQLSERVER service.
Screenshot of the steps:
And the simplest solution - check if your slash is back...
I spent about an hour trying to figure out what's wrong with SERVER/INSTANCENAME when everything is configured correctly, named pipes, user access rights... and suddenly it struck me, it's not a slash, it's a backslash (\).
The horror, the shame...
It's a three step process really after installing SQL Server:
Enable Named Pipes
SQL Config Manager --> SQL Server Network Consif --> Protocols --> Named Pipes --> Right-click --> Restart
Restart the server
SQL Config Manager --> SQL Server Services --> SQL Server (SQLEXPRESS) --> Right-click --> Restart
Use proper server and instance names (both are needed!)
Typically this would be .\SQLEXPRESS, for example see the screenshot from QueryExpress connection dialog.
There you have it.
I had just installed SQL SERVER 2012 developer. When I was creating my first SSIS package, I received this pipes error when I was trying to create a data connection task in SQL Server 2012 Data Tools in the Connection Manager box. I resolved with the help of the post above.
If choose a named instance and you call your named instance SSQDatabase1 and your pc's name is PCX1. You must enter PCX1\SSQDatabase1 not just SSQDatabase1
or you will receive the named pipes error.
A thread on MSDN Social, Re: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server, has a pretty decent list of possible issues that are related to your error. You may want to see if any of them could be what you're experiencing.
Incorrect connection string, such as using SqlExpress
Named Pipes(NP) was not enabled on the SQL instance
Remote connection was not enabled
Server not started, or point to not a real server in your connection string
Other reasons such as incorrect security context
try basic connectivity tests between the two machines you are working on
i Just enabled TCP/IP,VIA,Named Pipes in Sql Server Configuration manager , My problem got solved refer this for more info Resolving Named Pipes Error 40
Use SERVER\\ INSTANCE NAME .Using double backslash in my project solved my problem.
Thanks to Damian...
TCP/IP
Named Pipes
... both enabled
Web Config....(for localhost)
<add name="FooData" connectionString="Data Source=localhost\InstanceName;Initial Catalog=DatabaseName;Integrated Security=True;" providerName="System.Data.SqlClient" />
Did have the same problem. Spent like 6 hours when had to migrate some servers.
Tried all suggestions available on this topic and others.
Solution was as simple as server restart!
Very simple solution
use (local)\InstanceName
that's it. it worked for me.
TL;DR; Your SQL Server instance is using dynamic ports which is not working. Force SQL Server to use static port # 1433.
Complete Details: First of all this problem is more likely if you've a mix of default and named instance or named instances only(which was my case).
Key concept: Each instance of Microsoft SQL Server installed on a computer uses a different port to listen for incoming connection requests. Default instance of SQL Server uses port # 1433. As you install named instances then they will start using dynamic ports which is decided at the time of start-up of Windows service corresponding to named SQL Server instance.
My code was failing (with error code 40) to connect to the only named SQL Server instance that I had on my VM. You can try below possible solutions:
Solution # 1: Client code trying to connect to SQL Server instance takes help from SQL Server browser service to figure out port number at which your named instance is listening for incoming connections. Make sure SQL browser service is running on your computer.
Solution # 2: Check the port # (in yellow color) your named SQL Server instance is using from SQL Server configuration manager as shown in the snapshot below:
Use that port number explicitly in your connection string or with sqlcmd shown below:
sqlcmd -s mymachinename,11380 -i deleteDB.sql -o SQLDelete.txt
Solution # 3: Force your named instance to use port # 1433 which is used by default instance. Remember this will work only if you don't have any default SQL Server instance on your computer as the default SQL Server instance would be using using port # 1433 already. Same port number can't be uses by two different Windows services.
Mark TCP Dynamic ports field to blank and TCP Port field to 1433.
Change the port number in your connection string as shown below:
sqlcmd -s mymachinename\instanceName -i deleteDB.sql -o SQLDelete.txt
OR
sqlcmd -s mymachinename,1433 -i deleteDB.sql -o SQLDelete.txt
Note: Every change in TCP/IP settings requires corresponding Windows service restart.
Interestingly enough after resolving the error when I went back to dynamic port setting to reproduce the same error then it didn't happen. Not sure why.
Please read below interesting threads to know more about dynamic ports of SQL Server:
How to configure SQL Server Port on multiple instances?
When is a Dynamic Port “dynamic”?
When to use a TCP dynamic port and when TCP Port?
I got leads to solution of my problem from this blog.
in my case, i had a standalone server, i changed the sql server port default port 1433 in configuration manager to some number and restarted the sql serve service to take effect,i was able to connect to the sql server through management studio if i login to the server. but i was not able to connect from my local machine through sql server, i was getting the 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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 5)
I checked and verified all the below
-Named pipes/TCP is enabled.
-Remote connections are allowed.
-Windows Firewall is off
-Created an exception for portin Windows Firewall( this was not necessary in my case as the server is in same subnet network).
-Enabled everything in SQL Server Configuration Manager.
then i chnaged back the port number to default 1433 and restarted the sql server service, and the issue got resolved and i am able to connect the sql server from my local management studio.
I had the same problem. I use the MSSQL Server Management Studio 2017 and solved this problem using these steps:
Check for working fine SQL Server Services services or not.
Also check for working in good condition SQL Server (MSSQLSERVER).
Also check for working fine SQL Server Browser.
Restart SQL Server (MSSQLSERVER)
and fixed it.
You will find most likely your DB name is not correct, you will see the server name in VS like "DESKTOP-0I14BKI" but if you open up SSMS you will see DESKTOP-0I14BKI\SQLBLAHBLAH , simply add "\SQLBLAHBLAH" (instance name) to your "server name" in VS connection properties.
You will see:
To Fix:
Try the following steps:
Open Services window (open "run box" and type services.msc).
Looking for SQL services (with SQL prefix).
Start them (if cannot start. Goto step 4).
Right_click to each service -> Properties -> Change to tab "Log on"-> choise log on as "Local ..." -> 0K. Then start SQL services again.
Try Open SQL and connect database.
In my case,
I opened SQL Server Management Studio and searched for SQLEXPRESS in my Database engine.
It had two instances and I selected the correct one.
If you are working with Asp.net core and using appsettings.json than write server as localhost and after write sql instance name for enabled named pipe like this
"ConnectionString": {
"dewDB": "server=localhost\\dewelopersql;database=dewdb;User ID=sa;password=XXXXX",
},
After following all the steps mentioned here, if it still does not connect, try adding the DNS with the IP address in the hosts file in the etc folder. Adding an IP address instead of DNS name in the connection string should be a temporary solution to check if the connection actually works.
I tried using the local IP address to connect as well as a public one.
I've tried:
Yes, the site can communicate with the server Named pipes/TCP is
enabled. Remote connections are allowed. Windows Firewall is off
Created an exception for port 1433 in Windows Firewall. Enabled
everything in SQL Server Configuration Manager.
i ensured and did the above as well and I just want to share that the DOUBLE BACKSLASH
oBuilder.DataSource = "SPECIFICPCNAME\SQLEXPRESS";
Using a SINGLE BACKSLASH resulted into a build error i.e.: Error 1 Unrecognized escape sequence
I hope this helps the next guy - I've sacrificed dinner, midnight snack and NBA highlights time solving this (shame)
Thanks to [Tamizh venthan]
^_^
Enable TCP/Ip , Piped Protocol by going to Computer Management ->SQL and Services, ensure the Service is On. Enbale the port on the Firewall. Try to login through Command Prompt -> as Admin; last the User Name
should be (local)\SQLEXPRESS. Hope this helps.
Open SQL Server Configuration Manager
Select SQL Server Services from right.
Find your server from right and go to its properties (with right click)
Change log on method to Local System.
I had the same problem and solved the problem by disabling my firewall(ESET).
The first step to solve this problem should be to try pinging your own computer from another computer. If you have firewall on, you may not be able to ping yourself. I tried pinging my own pc, then ping was failed(didnt get response from the server)
I was trying to add a new connection in VS2015. None of the suggestions here worked. Suspecting some sort of a bug in the wizard, especially since SSMS was able to connect just fine, I decided to try and trick it. It worked!
Instead of adding the connection, use "Create new SQL Server Database". Enter your server name and a random name for the new DB, e.g. "test".
Assuming this succeeds, open Server Explorer in VS, locate the connection in Data Connections, right-click it and select Modify Connection.
Change "test" (from step 1) to the name of the existing database you want to connect to. Click "Test Connection". This time it should work!
Delete the temporary database you created in step 1.
I have one more solution, I think.
I recently had changed my computer name so, after I couldn't connect still after trying all above methods.
I changed the Server name..
Server name => (browse for more) => under database engine, a new server was found same as computers new name.
This worked, and life is good again.
I struggled for ages on this one before I realized my error - I had used commas instead of semicolons in the connect string
I had this issue but none of the suggestions above fixed it.
I was seeing this issue when I deployed my website to IIS. The fix was to go into advanced settings against the default app pool and change the identity property from the default to Administrator.
For me it was a Firewall issue.
First you have to add the port (such as 1444 and maybe 1434) but also
C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe
and
%ProgramFiles%\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQL\Binn\SQLAGENT.EXE
The second time I got this issue is when I came back to the firewall, the paths were not correct and I needed to update form 12 to 13! Simply clicking on browse in the Programs and Services tab helped to realise this.
Finally, try running the command
EXEC xp_readerrorlog 0,1,"could not register the Service Principal Name",Null
For me, it returned the error reason
I tried pretty much everything on this page but I had some underlying issues which were actually what needed to be resolved. I was unable to do certain things like open SQL Server Configuration Manager, which ended up being corrupt/missing WMI provider files.
There are lots of tedious ways to resolve this issues according to what I've read, but the tool from tweaking.com was able to remove and replace/repair my WMI (Windows Management Instrumentation) Provider files.
I used to do computer repair and overall the tweaking.com tool really impressed me, and it was suggested from one of the WMI error forum pages I went to.
After I fixed this issue I was able to connect to my SQL db, both locally and remotely.
Hope this helps someone.
open port number 1433 on your server for sql remote connection
If you tried restarting the MSSQLSERVER service, and it did not work, this might be a solution:
If you are using SQLExpress, your server name should be as the following ComputerName\SQLExpress. However, for SQLDeveloper, you do not have to right SQLDeveloper after your ComputerName.
I can't seem to connect to my database from a site. I get this error:
Named Pipes Provider, error: 40 - Could not open a connection to SQL Server
I tried using the local IP address to connect as well as a public one. I've tried:
Yes, the site can communicate with the server
Named pipes/TCP is enabled.
Remote connections are allowed.
Windows Firewall is off
Created an exception for port 1433 in Windows Firewall.
Enabled everything in SQL Server Configuration Manager.
What else can I do here?
Solving this problem is very easy:
Go to control panel.
search for services.
Open Local services window from your search results
Restart your MSSQLSERVER service.
Screenshot of the steps:
And the simplest solution - check if your slash is back...
I spent about an hour trying to figure out what's wrong with SERVER/INSTANCENAME when everything is configured correctly, named pipes, user access rights... and suddenly it struck me, it's not a slash, it's a backslash (\).
The horror, the shame...
It's a three step process really after installing SQL Server:
Enable Named Pipes
SQL Config Manager --> SQL Server Network Consif --> Protocols --> Named Pipes --> Right-click --> Restart
Restart the server
SQL Config Manager --> SQL Server Services --> SQL Server (SQLEXPRESS) --> Right-click --> Restart
Use proper server and instance names (both are needed!)
Typically this would be .\SQLEXPRESS, for example see the screenshot from QueryExpress connection dialog.
There you have it.
I had just installed SQL SERVER 2012 developer. When I was creating my first SSIS package, I received this pipes error when I was trying to create a data connection task in SQL Server 2012 Data Tools in the Connection Manager box. I resolved with the help of the post above.
If choose a named instance and you call your named instance SSQDatabase1 and your pc's name is PCX1. You must enter PCX1\SSQDatabase1 not just SSQDatabase1
or you will receive the named pipes error.
A thread on MSDN Social, Re: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server, has a pretty decent list of possible issues that are related to your error. You may want to see if any of them could be what you're experiencing.
Incorrect connection string, such as using SqlExpress
Named Pipes(NP) was not enabled on the SQL instance
Remote connection was not enabled
Server not started, or point to not a real server in your connection string
Other reasons such as incorrect security context
try basic connectivity tests between the two machines you are working on
i Just enabled TCP/IP,VIA,Named Pipes in Sql Server Configuration manager , My problem got solved refer this for more info Resolving Named Pipes Error 40
Use SERVER\\ INSTANCE NAME .Using double backslash in my project solved my problem.
Thanks to Damian...
TCP/IP
Named Pipes
... both enabled
Web Config....(for localhost)
<add name="FooData" connectionString="Data Source=localhost\InstanceName;Initial Catalog=DatabaseName;Integrated Security=True;" providerName="System.Data.SqlClient" />
Did have the same problem. Spent like 6 hours when had to migrate some servers.
Tried all suggestions available on this topic and others.
Solution was as simple as server restart!
Very simple solution
use (local)\InstanceName
that's it. it worked for me.
TL;DR; Your SQL Server instance is using dynamic ports which is not working. Force SQL Server to use static port # 1433.
Complete Details: First of all this problem is more likely if you've a mix of default and named instance or named instances only(which was my case).
Key concept: Each instance of Microsoft SQL Server installed on a computer uses a different port to listen for incoming connection requests. Default instance of SQL Server uses port # 1433. As you install named instances then they will start using dynamic ports which is decided at the time of start-up of Windows service corresponding to named SQL Server instance.
My code was failing (with error code 40) to connect to the only named SQL Server instance that I had on my VM. You can try below possible solutions:
Solution # 1: Client code trying to connect to SQL Server instance takes help from SQL Server browser service to figure out port number at which your named instance is listening for incoming connections. Make sure SQL browser service is running on your computer.
Solution # 2: Check the port # (in yellow color) your named SQL Server instance is using from SQL Server configuration manager as shown in the snapshot below:
Use that port number explicitly in your connection string or with sqlcmd shown below:
sqlcmd -s mymachinename,11380 -i deleteDB.sql -o SQLDelete.txt
Solution # 3: Force your named instance to use port # 1433 which is used by default instance. Remember this will work only if you don't have any default SQL Server instance on your computer as the default SQL Server instance would be using using port # 1433 already. Same port number can't be uses by two different Windows services.
Mark TCP Dynamic ports field to blank and TCP Port field to 1433.
Change the port number in your connection string as shown below:
sqlcmd -s mymachinename\instanceName -i deleteDB.sql -o SQLDelete.txt
OR
sqlcmd -s mymachinename,1433 -i deleteDB.sql -o SQLDelete.txt
Note: Every change in TCP/IP settings requires corresponding Windows service restart.
Interestingly enough after resolving the error when I went back to dynamic port setting to reproduce the same error then it didn't happen. Not sure why.
Please read below interesting threads to know more about dynamic ports of SQL Server:
How to configure SQL Server Port on multiple instances?
When is a Dynamic Port “dynamic”?
When to use a TCP dynamic port and when TCP Port?
I got leads to solution of my problem from this blog.
in my case, i had a standalone server, i changed the sql server port default port 1433 in configuration manager to some number and restarted the sql serve service to take effect,i was able to connect to the sql server through management studio if i login to the server. but i was not able to connect from my local machine through sql server, i was getting the 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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 5)
I checked and verified all the below
-Named pipes/TCP is enabled.
-Remote connections are allowed.
-Windows Firewall is off
-Created an exception for portin Windows Firewall( this was not necessary in my case as the server is in same subnet network).
-Enabled everything in SQL Server Configuration Manager.
then i chnaged back the port number to default 1433 and restarted the sql server service, and the issue got resolved and i am able to connect the sql server from my local management studio.
I had the same problem. I use the MSSQL Server Management Studio 2017 and solved this problem using these steps:
Check for working fine SQL Server Services services or not.
Also check for working in good condition SQL Server (MSSQLSERVER).
Also check for working fine SQL Server Browser.
Restart SQL Server (MSSQLSERVER)
and fixed it.
You will find most likely your DB name is not correct, you will see the server name in VS like "DESKTOP-0I14BKI" but if you open up SSMS you will see DESKTOP-0I14BKI\SQLBLAHBLAH , simply add "\SQLBLAHBLAH" (instance name) to your "server name" in VS connection properties.
You will see:
To Fix:
Try the following steps:
Open Services window (open "run box" and type services.msc).
Looking for SQL services (with SQL prefix).
Start them (if cannot start. Goto step 4).
Right_click to each service -> Properties -> Change to tab "Log on"-> choise log on as "Local ..." -> 0K. Then start SQL services again.
Try Open SQL and connect database.
In my case,
I opened SQL Server Management Studio and searched for SQLEXPRESS in my Database engine.
It had two instances and I selected the correct one.
If you are working with Asp.net core and using appsettings.json than write server as localhost and after write sql instance name for enabled named pipe like this
"ConnectionString": {
"dewDB": "server=localhost\\dewelopersql;database=dewdb;User ID=sa;password=XXXXX",
},
After following all the steps mentioned here, if it still does not connect, try adding the DNS with the IP address in the hosts file in the etc folder. Adding an IP address instead of DNS name in the connection string should be a temporary solution to check if the connection actually works.
I tried using the local IP address to connect as well as a public one.
I've tried:
Yes, the site can communicate with the server Named pipes/TCP is
enabled. Remote connections are allowed. Windows Firewall is off
Created an exception for port 1433 in Windows Firewall. Enabled
everything in SQL Server Configuration Manager.
i ensured and did the above as well and I just want to share that the DOUBLE BACKSLASH
oBuilder.DataSource = "SPECIFICPCNAME\SQLEXPRESS";
Using a SINGLE BACKSLASH resulted into a build error i.e.: Error 1 Unrecognized escape sequence
I hope this helps the next guy - I've sacrificed dinner, midnight snack and NBA highlights time solving this (shame)
Thanks to [Tamizh venthan]
^_^
Enable TCP/Ip , Piped Protocol by going to Computer Management ->SQL and Services, ensure the Service is On. Enbale the port on the Firewall. Try to login through Command Prompt -> as Admin; last the User Name
should be (local)\SQLEXPRESS. Hope this helps.
Open SQL Server Configuration Manager
Select SQL Server Services from right.
Find your server from right and go to its properties (with right click)
Change log on method to Local System.
I had the same problem and solved the problem by disabling my firewall(ESET).
The first step to solve this problem should be to try pinging your own computer from another computer. If you have firewall on, you may not be able to ping yourself. I tried pinging my own pc, then ping was failed(didnt get response from the server)
I was trying to add a new connection in VS2015. None of the suggestions here worked. Suspecting some sort of a bug in the wizard, especially since SSMS was able to connect just fine, I decided to try and trick it. It worked!
Instead of adding the connection, use "Create new SQL Server Database". Enter your server name and a random name for the new DB, e.g. "test".
Assuming this succeeds, open Server Explorer in VS, locate the connection in Data Connections, right-click it and select Modify Connection.
Change "test" (from step 1) to the name of the existing database you want to connect to. Click "Test Connection". This time it should work!
Delete the temporary database you created in step 1.
I have one more solution, I think.
I recently had changed my computer name so, after I couldn't connect still after trying all above methods.
I changed the Server name..
Server name => (browse for more) => under database engine, a new server was found same as computers new name.
This worked, and life is good again.
I struggled for ages on this one before I realized my error - I had used commas instead of semicolons in the connect string
I had this issue but none of the suggestions above fixed it.
I was seeing this issue when I deployed my website to IIS. The fix was to go into advanced settings against the default app pool and change the identity property from the default to Administrator.
For me it was a Firewall issue.
First you have to add the port (such as 1444 and maybe 1434) but also
C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe
and
%ProgramFiles%\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQL\Binn\SQLAGENT.EXE
The second time I got this issue is when I came back to the firewall, the paths were not correct and I needed to update form 12 to 13! Simply clicking on browse in the Programs and Services tab helped to realise this.
Finally, try running the command
EXEC xp_readerrorlog 0,1,"could not register the Service Principal Name",Null
For me, it returned the error reason
I tried pretty much everything on this page but I had some underlying issues which were actually what needed to be resolved. I was unable to do certain things like open SQL Server Configuration Manager, which ended up being corrupt/missing WMI provider files.
There are lots of tedious ways to resolve this issues according to what I've read, but the tool from tweaking.com was able to remove and replace/repair my WMI (Windows Management Instrumentation) Provider files.
I used to do computer repair and overall the tweaking.com tool really impressed me, and it was suggested from one of the WMI error forum pages I went to.
After I fixed this issue I was able to connect to my SQL db, both locally and remotely.
Hope this helps someone.
open port number 1433 on your server for sql remote connection
If you tried restarting the MSSQLSERVER service, and it did not work, this might be a solution:
If you are using SQLExpress, your server name should be as the following ComputerName\SQLExpress. However, for SQLDeveloper, you do not have to right SQLDeveloper after your ComputerName.
I have been trying to figure this out for days now... I have this old application that I have not had to mess with in years and this old windows 2000 (32bit) machine went out on me. So I ended up replacing that machine with a new Windows 7 (64bit) machine.
Everything seems to be working just fine with the exception of one thing. When I try to connect to the database with the app it keeps prompting me for a password as if it's not able to connect or see the server is a SQL Server in the first place!
I have tested the connection with the ODBC Data Source Administrator and that worked perfectly "TESTS COMPLETED SUCCESSFULLY!". But when I try to connect using my app it just times out and asks for me to enter the user/pass again. :/
I had another old machine (windows 2000 32bit) up and running and it was accessing the db just fine so I know the server is setup right with open ports and no firewall etc..
I just can't seem to find a reason this client will not connect! Any ideas?
Update #1:
It seems that when turning on logging auditing in the SQL Server Management Studio I was able to see the following two log entries (in the following order)...
TEST #1
Login succeeded for user 'pubclient'. Connection made using SQL
Server authentication.
Login failed for user 'pubclient'. Reason:
Failed to open the explicitly specified database.
So when I try this on the local client machine with the temp install of SQL Server 2008 r2 it works perfectly fine. Same exact settings just a different host in the settings ini file used!
TEST #2
Login succeeded for user 'pubclient'. Connection made using SQL Server
authentication.
Starting up database 'iri'.
Login succeeded for user 'pubclient'. Connection made using SQL Server
authentication.
I don't have to specify a database on the local machine (client->client), so why do I when trying to connect from client->server?
UPDATE #2
So from what I can tell at this point is if I use a bogus host (one that can not be pinged) this application will ask me for a user/pass (because it can not make a connection to anything). If I use a host that does respond to a ping it seems to be happy and proceed. By proceed I mean it will connect to the correct remote server (as shown in UPDATE #1 on TEST #2) but before it does the second login attempt (Login succeeded for user 'pubclient'. Connection made using SQL Server authentication.) it decides to try and connect to the LOCAL SQL server I set up as a test on the client machine!!! I do not have the client host listed ANYWHERE in the settings (the client machine name was just made up so it's not hard coded). For some reason now that I have upgraded the client PC to Windows 7 64bit (from Windows 2000 32bit) it wants to continue trying to connect to the local machine instead of the remote host like it does initially!! WHAT THE HECK! I have no clue why it wants to connect to the localhost instead but this does NOT happen on Windows 2000...
I would suggest trying a "more exact" connection-string.
https://www.connectionstrings.com/sqlconnection/connect-via-an-ip-address/
Data Source=190.190.200.100,1433;Network Library=DBMSSOCN;
Initial Catalog=myDataBase;User ID=myUsername;Password=myPassword;
or
Data Source=190.190.200.100,1433;Network Library=DBMSSOCN;
Initial Catalog=myDataBase;Trusted_Connection=True;
This connection string has an IP address and Port, specifies the Network Library (tcp/ip) (Do a search for dbmssocn and you'll find the others, but dbmssocn is the first one to try). The first one above is for sql server authentication...the second one is for integrated-security.
I mention this because I had issues with a client that would not work with named-pipes, but worked with tcp.
It's not a great chance this is it, but its worth a shot.
I see you are using ODBC. You need to make sure you set up a 32 bit ODBC. To do that you must use ODBCAD32.exe in the wow64 directory. The default ODBC admin on the start menu goes to the 64 bit, and your app (being 32 bit) will not see this. So it might be a crappy app hiding the fact that it can't find a DSN with a login error message.
Take a look at this https://superuser.com/questions/419832/how-can-i-open-the-32-bit-odbc-data-source-administrator-in-windows-7-64-bit and please confirm that your app is running in 32 bit mode (has a star next to it in task manager)
I am struggling to get a SQL Server connection from machine A to machine B which is running the SQL Server.
I have Googled extensively and all the things I have found have not worked. Nor do they lead you step by step through the process of solving this.
We are not using Kerberos, but NTLM where configured.
The machines involved are (xx is used to obscure some of the machine name for security purposes):
xxPRODSVR001 - Windows Server 2012 Domain Controller
xxDEVSVR003 - Windows Server 2012 (This machine is generating the error)
xxDEVSVR002 - Windows Server 2012 (This machine is running SQL Server 2012)
The following SPN's are registered on the DC (xxPRODSVR001). I have obscured the domain with yyy for security purposes:
Registered ServicePrincipalNames for CN=xxDEVSVR002,CN=Computers,DC=yyy,DC=local:
MSSQLSvc/xxDEVSVR002.yyy.local:49298
MSSQLSvc/xxDEVSVR002.yyy.local:TFS
RestrictedKrbHost/xxDEVSVR002
RestrictedKrbHost/xxDEVSVR002.yyy.local
Hyper-V Replica Service/xxDEVSVR002
Hyper-V Replica Service/xxDEVSVR002.yyy.local
Microsoft Virtual System Migration Service/xxDEVSVR002
Microsoft Virtual System Migration Service/xxDEVSVR002.yyy.local
Microsoft Virtual Console Service/xxDEVSVR002
Microsoft Virtual Console Service/xxDEVSVR002.yyy.local
SMTPSVC/xxDEVSVR002
SMTPSVC/xxDEVSVR002.yyy.local
WSMAN/xxDEVSVR002
WSMAN/xxDEVSVR002.yyy.local
Dfsr-12F9A27C-BF97-4787-9364-D31B6C55EB04/xxDEVSVR002.yyy.local
TERMSRV/xxDEVSVR002
TERMSRV/xxDEVSVR002.yyy.local
HOST/xxDEVSVR002
HOST/xxDEVSVR002.yyy.local
Registered ServicePrincipalNames for CN=xxDEVSVR003,CN=Computers,DC=yyy,DC=local:
MSSQLSvc/xxDEVSVR003.yyy.local:1433
MSSQLSvc/xxDEVSVR003.yyy.local
Hyper-V Replica Service/xxDEVSVR003
Hyper-V Replica Service/xxDEVSVR003.yyy.local
Microsoft Virtual System Migration Service/xxDEVSVR003
Microsoft Virtual System Migration Service/xxDEVSVR003.yyy.local
Microsoft Virtual Console Service/xxDEVSVR003
Microsoft Virtual Console Service/xxDEVSVR003.yyy.local
WSMAN/xxDEVSVR003
WSMAN/xxDEVSVR003.yyy.local
TERMSRV/xxDEVSVR003
TERMSRV/xxDEVSVR003.yyy.local
RestrictedKrbHost/xxDEVSVR003
HOST/xxDEVSVR003
RestrictedKrbHost/xxDEVSVR003.yyy.local
HOST/xxDEVSVR003.yyy.local
Now if only the SQL Server error message was more descriptive and told me what principal name it was trying to connect to I might be able to diagnose this.
So can anyone step me through how to solve this one or can you see anything in what I have provided that is wrong?
I would be happy to generate more debug info, just tell me what you need.
I had this problem with an ASP.NET MVC app I was working on.
I realized I had recently changed my password, and I was able to fix it by logging out and logging back in again.
The SSPI context error definitely indicates authentication is being attempted using Kerberos.
Since Kerberos authentication SQL Server's Windows Authentication relies on Active Directory, which requires a trusted relationship between your computer and your network domain controller, you should start by validating that relationship.
You can quickly check that relationship, thru the following Powershell command Test-ComputerSecureChannel.
Test-ComputerSecureChannel -Verbose
If it returns False, you must repair your computer Active Directory secure channel, since without it no domain credencials validation is possible outside your computer.
You can repair your Computer Secure Channel, thru the following Powershell command:
Test-ComputerSecureChannel -Repair -Verbose
If the above doesn't work (because your domain credentials don't work because the machine isn't trusted) you can use NETDOM RESET instead from an elevated cmd.exe (not PowerShell) prompt:
NETDOM RESET %COMPUTERNAME% /UserO:domainAdminUserName /Password0:* /SecurePasswordPrompt
(Yes, the command-line arguments really do have an O (Capital-"Oh", not zero 0). The /Password0:* /SecurePasswordPrompt option will use a credential popup instead of having you put your password directly in the command-line, which you must never do).
Check the security event logs, if you are using kerberos you should see logon attempts with authentication package: Kerberos.
The NTLM authentication may be failing and so a kerberos authentication attempt is being made. You might also see an NTLM logon attempt failure in your security event log?
You can turn on kerberos event logging in dev to try to debug why the kerberos is failing, although it is very verbose.
Microsoft's Kerberos Configuration Manager for SQL Server may help you quickly diagnose and fix this issue.
Here is a good story to read: http://houseofbrick.com/microsoft-made-an-easy-button-for-spn-and-double-hop-issues/
I was getting the same error when trying through windows authentication. Sounds ludicrous but just in case it helps someone else: it was because my domain account got locked somehow while I was still logged in (!). Unlocking the account fixed it.
Try setting Integrated Security=true to remove this param from the connection string.
IMPORTANT: As user #Auspex commented,
Removing Integrated Security will prevent this error, because the error occurs when trying to login with your Windows credentials. Unfortunately, most of the time, you want to be able to login with your Windows credentials
I was logging into Windows 10 with a PIN instead of a password. I logged out and logged back in with my password instead and was able to get in to SQL Server via Management Studio.
Just to add another potential solution to this most ambiguous of errors The target principal name is incorrect. Cannot generate SSPI context. (.Net SqlClient Data Provider) :
Verify that the IP that is resolved when pinging the SQL Server is the same as the one in the Configuration Manager. To check, open SQL Server Configuration Manager and then go to SQL Server Network Configuration > Protocols for MSSQLServer > TCP/IP.
Make sure TCP/IP is enabled and in the IP Addresses tab, make sure that the IP that the server resolves to when pinging is the same one here. That fixed this error for me.
I just ran into this and fixed it by doing 2 things:
Granting read/write servicePrincipalName permissions to the service account using ADSI Edit, as described in https://support.microsoft.com/en-us/kb/811889
Removing the SPNs that previously existed on the SQL Server computer account (as opposed to the service account) using
setspn -D MSSQLSvc/HOSTNAME.domain.name.com:1234 HOSTNAME
where 1234 was the port number used by the instance (mine was not a default instance).
This is usually due to missing, incorrect or duplicated Service Principle Names (SPNs)
Steps to resolve:
Confirm what AD account SQL Server is using
Run the following command in Powershell or CMD in administrator mode (service account should not contain the domain)
setspn -L <ServiceAccountName> | Select-String <ServerName> | select line
Make sure the returned output contains an SPN which is fully qualified, no fully qualified, with a port and without a port.
Expected Output:
Registered ServicePrincipalNames for CN=<ServiceAccountName>,OU=CSN Service Accounts,DC=<Domain>,DC=com:
MSSQLSvc/<ServerName>.<domain>.com:1433
MSSQLSvc/<ServerName>:1433
MSSQLSvc/<ServerName>.<domain>.com
MSSQLSvc/<ServerName>
If you don't see all of the above, run the following command in PowerShell or CMD in admin mode (make sure to change the port if you don't use default 1433)
SETSPN -S MSSQLSvc/<ServerName> <Domain>\<ServiceAccountName>
SETSPN -S MSSQLSvc/<ServerName>.<Domain> <Domain>\<ServiceAccountName>
SETSPN -S MSSQLSvc/<ServerName>:1433 <Domain>\<ServiceAccountName>
SETSPN -S MSSQLSvc/<ServerName>.<Domain>:1433 <Domain>\<ServiceAccountName>
Once above is complete it normally takes a few minutes for DNS propagation
Also, if you get a message about duplicate SPNs found, you may want to delete them and recreate them
The issue seems to be a windows credentials issue. I was getting the same error on my work laptop with a VPN. I am supposedly logged in as my Domain/Username, which is what I use successfully when connecting directly but as soon as I move to a VPN with another connection I receive this error. I thought it was a DNS issue as I could ping the server but it turns out I needed to run SMSS explicitly as my user from Command prompt.
e.g
runas /netonly /user:YourDoman\YourUsername "C:\Program Files (x86)\Microsoft SQL Server Management Studio 18\Common7\IDE\Ssms.exe"
Login to both your SQL Box and your client and type:
ipconfig /flushdns
nbtstat -R
If that doesn't work, renew your DHCP on your client machine... This work for 2 PCs in our office.
Check your clock matches between the client and server.
When I had this error intermittently, none of the above answers worked, then we found the time had drifted on some of our servers, once they were synced again the error went away. Search for w32tm or NTP to see how to automatically sync the time on Windows.
In my case, restarting SQL Server 2014 (on my development server) fixed the issue.
I had this problem when accessing the web application. It might be due to i have changed a windows password recently.
This issue got resolved when i have updated the password for the app pool where i have hosted the web application.
I was testing out IPv6 on a cluster of PC's in an isolated network and ran into this issue when I reverted back yo IPv4. I had been play in the active directory, DNS and DHCP so have no idea what I prodded to break the Kerberos setup.
I retested the connection outside of my software with this useful tip to connect remote connectivity I found.
https://blogs.msdn.microsoft.com/steverac/2010/12/13/test-remote-sql-connectivity-easily/
then after a brief search found this on the Microsoft website
https://support.microsoft.com/en-gb/help/811889/how-to-troubleshoot-the-cannot-generate-sspi-context-error-message.
run the tool on the SQL server see if there are any issue
if the status says error then hit the fix button that appears.
This resolved the problem for me.
In my situation I was trying to use Integrated Security to connect from a PC to SQL Server on another PC on a network without a domain. On both PCs, I was signing in to Windows with the same Microsoft account. I switched to a local account on both PCs and SQL Server now connects successfully.
I had the same issue, but locking, and unlocking the machine worked for me. Sometimes, firewall issues will give errors.
I am not sure it will work for you or not, just sharing my experience.
This Microsoft Tool is like Magic. Run it, connect it to the SQL server, and click Fix
The old version linked here worked on SQL server 2017.
Kerberos Configuration Manager for SQL Server
https://www.microsoft.com/en-us/download/details.aspx?id=39046
Since I landed here when looking for a solution to my own problem, I'll share my solution here, in case others land here as well.
I was connecting fine to SQL Server until my machine was moved to another office on another domain. Then, after the switch, I was getting this error regarding the target principal name. What fixed it was connecting using a fully qualified name such as: server.domain.com. And actually, once I connected to the first server that way, I could connect to other servers using just the server name (without the full qualification), but your mileage may vary.
In my Case since I was working in my development environment, someone had shut down the Domain Controller and Windows Credentials couldn't be authenticated. After turning on the Domain Controller, the error disappeared and everything worked just fine.
In case anyone is wondering, I untangled the MS terminology:
Target = (active directory) target
Active directory target = target server running the domain controller
Domain controller = server that verifies your login information
Principal name = your windows username
SSPI = security support provider interface
Security support provider interface = software interface that manages "authenticated
communications" and allows SSPs like TLS to allow SSL, among others
SSP = security support provider (SSPI implementation)
TLS/SSL = you should already know this
= Can't verify your password.
I ran into this today and wanted to share my fix, since this one is simply overlooked and easy to fix.
We manage our own rDNS and recently redid our server naming scheme. As part of that, we should have updated our rDNS and forgot to do this.
A ping turned up the correct hostname, but a ping -a returned the wrong hostname.
Easy fix: change the rDNS, do an ipconfig /flushdns, wait 30 seconds (just something I do), do another ping -a , see it resolving the correct hostname, connect ... profit.
I ran into a variant of this issue, here were the characteristics:
User was able to successfully connect to a named instance, for example, connections to Server\Instance were successful
User was unable to connect to the default instance, for example, connections to Server failed with the OP's screenshot regarding SSPI
User was unable to connect default instance with fully qualified name, for example, connections to Server.domain.com failed (timeout)
User was unable to connect IP address without named instance, for example, connections to 192.168.1.134 failed
Other users not on the domain (for example, users who VPN to the network) but using domain credentials were able to successfully connect to the default instance and IP address
So after many headaches of trying to figure out why this single user couldn't connect, here are the steps we took to fix the situation:
Take a look at the server in the SPN list using
setspn -l Server
a. In our case, it said Server.domain.com
Add an entry to the hosts file located in C:\Windows\System32\drivers\etc\hosts (run Notepad as Administrator to alter this file). The entry we added was
Server.domain.com Server
After this, we were able to successfully connect via SSMS to the default instance.
I ran into a new one for this: SQL 2012 hosted on Server 2012.
Was tasked to create a cluster for SQL AlwaysOn.
Cluster was created everyone got the SSPI message.
To fix the problems ran following command:
setspn -D MSSQLSvc/SERVER_FQNName:1433 DomainNamerunningSQLService
DomainNamerunningSQLService == the domain account I set for SQL
I needed a Domain Administrator to run the command. Only one server in the cluster had issues.
Then restarted SQL. To my surprise I was able to connect.
I was trying to connect to a VM running SQL Server 2015 from my laptop in a Visual Studio 2015 Console App. I run my app the night before and it is fine. In the morning I try to debug the app and I get this error. I tried ipconfig/flush and release + renew and a a bunch of other garbage, but in the end...
Restart your VM and restart the client. That fixed it for me. I should have known, restart works every time.
I had this problem on my sql server. I setspn -D mssqlsvc\Hostname.domainname Hostname then stoped and started my SQL server service.
I am thinking that just stopping and starting my sql service would have done it.
I have tried all the solutions here and none of them have worked yet. A workaround that is working is to Click Connect, enter the server name, select Options, Connection Properties tab. Set the "Network protocol" to "Named Pipes". This allows users to remote connect using their network credentials. I'll post an update when I get a fix.
In my case, the problem was setting up DNS on the wifi. I removed the settings, and left them empty, and worked.
Make sure that "Named Pipes" are enabled from "SQL Server Configuration Manager". This worked for me.
Open "SQL Server Configuration Manager".
Expand "SQL Server Network Configuration", from the list on the left.
Select "Protocols for [Your Instance Name]".
Right click on "Named Pipes", from the list on the right.
Select "Enable"
Restart your Instance service.
Another niche to this issue caused by network connections. I connect via windows VPN client and this issue popped up when I switched from Wifi to a wired connection. The fix for my situation was to manually adjust the adapter metric.
In powershell use Get-NetIPInterface to see all of the metric values. The lower numbers are lower cost and so they are preferred by windows. I switched the ethernet and VPN and the credentials got where they needed to be for SSMS to be happy.
To configure the Automatic Metric feature:
In Control Panel, double-click Network Connections.
Right-click a network interface, and then select Properties.
Click Internet Protocol (TCP/IP), and then select Properties.
On the General tab, select Advanced.
To specify a metric, on the IP Settings tab, select to clear the Automatic metric check box, and then enter the metric that you want in the Interface Metric field.
Source:
https://learn.microsoft.com/en-us/troubleshoot/windows-server/networking/automatic-metric-for-ipv4-routes
I have been unable to solve this in a satisfactory manner. If I log in from a client as a local Windows account, Windows authentication works without a glitch. If I however attempt to log in from a Microsoft account (which is preferable for me because of the synchronization features), I get the "incorrect principal" message. No record of the failed login appears in the MS-SQL logs, implying that the failure occurs very early.
I can't seem to connect to my database from a site. I get this error:
Named Pipes Provider, error: 40 - Could not open a connection to SQL Server
I tried using the local IP address to connect as well as a public one. I've tried:
Yes, the site can communicate with the server
Named pipes/TCP is enabled.
Remote connections are allowed.
Windows Firewall is off
Created an exception for port 1433 in Windows Firewall.
Enabled everything in SQL Server Configuration Manager.
What else can I do here?
Solving this problem is very easy:
Go to control panel.
search for services.
Open Local services window from your search results
Restart your MSSQLSERVER service.
Screenshot of the steps:
And the simplest solution - check if your slash is back...
I spent about an hour trying to figure out what's wrong with SERVER/INSTANCENAME when everything is configured correctly, named pipes, user access rights... and suddenly it struck me, it's not a slash, it's a backslash (\).
The horror, the shame...
It's a three step process really after installing SQL Server:
Enable Named Pipes
SQL Config Manager --> SQL Server Network Consif --> Protocols --> Named Pipes --> Right-click --> Restart
Restart the server
SQL Config Manager --> SQL Server Services --> SQL Server (SQLEXPRESS) --> Right-click --> Restart
Use proper server and instance names (both are needed!)
Typically this would be .\SQLEXPRESS, for example see the screenshot from QueryExpress connection dialog.
There you have it.
I had just installed SQL SERVER 2012 developer. When I was creating my first SSIS package, I received this pipes error when I was trying to create a data connection task in SQL Server 2012 Data Tools in the Connection Manager box. I resolved with the help of the post above.
If choose a named instance and you call your named instance SSQDatabase1 and your pc's name is PCX1. You must enter PCX1\SSQDatabase1 not just SSQDatabase1
or you will receive the named pipes error.
A thread on MSDN Social, Re: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server, has a pretty decent list of possible issues that are related to your error. You may want to see if any of them could be what you're experiencing.
Incorrect connection string, such as using SqlExpress
Named Pipes(NP) was not enabled on the SQL instance
Remote connection was not enabled
Server not started, or point to not a real server in your connection string
Other reasons such as incorrect security context
try basic connectivity tests between the two machines you are working on
i Just enabled TCP/IP,VIA,Named Pipes in Sql Server Configuration manager , My problem got solved refer this for more info Resolving Named Pipes Error 40
Use SERVER\\ INSTANCE NAME .Using double backslash in my project solved my problem.
Thanks to Damian...
TCP/IP
Named Pipes
... both enabled
Web Config....(for localhost)
<add name="FooData" connectionString="Data Source=localhost\InstanceName;Initial Catalog=DatabaseName;Integrated Security=True;" providerName="System.Data.SqlClient" />
Did have the same problem. Spent like 6 hours when had to migrate some servers.
Tried all suggestions available on this topic and others.
Solution was as simple as server restart!
Very simple solution
use (local)\InstanceName
that's it. it worked for me.
TL;DR; Your SQL Server instance is using dynamic ports which is not working. Force SQL Server to use static port # 1433.
Complete Details: First of all this problem is more likely if you've a mix of default and named instance or named instances only(which was my case).
Key concept: Each instance of Microsoft SQL Server installed on a computer uses a different port to listen for incoming connection requests. Default instance of SQL Server uses port # 1433. As you install named instances then they will start using dynamic ports which is decided at the time of start-up of Windows service corresponding to named SQL Server instance.
My code was failing (with error code 40) to connect to the only named SQL Server instance that I had on my VM. You can try below possible solutions:
Solution # 1: Client code trying to connect to SQL Server instance takes help from SQL Server browser service to figure out port number at which your named instance is listening for incoming connections. Make sure SQL browser service is running on your computer.
Solution # 2: Check the port # (in yellow color) your named SQL Server instance is using from SQL Server configuration manager as shown in the snapshot below:
Use that port number explicitly in your connection string or with sqlcmd shown below:
sqlcmd -s mymachinename,11380 -i deleteDB.sql -o SQLDelete.txt
Solution # 3: Force your named instance to use port # 1433 which is used by default instance. Remember this will work only if you don't have any default SQL Server instance on your computer as the default SQL Server instance would be using using port # 1433 already. Same port number can't be uses by two different Windows services.
Mark TCP Dynamic ports field to blank and TCP Port field to 1433.
Change the port number in your connection string as shown below:
sqlcmd -s mymachinename\instanceName -i deleteDB.sql -o SQLDelete.txt
OR
sqlcmd -s mymachinename,1433 -i deleteDB.sql -o SQLDelete.txt
Note: Every change in TCP/IP settings requires corresponding Windows service restart.
Interestingly enough after resolving the error when I went back to dynamic port setting to reproduce the same error then it didn't happen. Not sure why.
Please read below interesting threads to know more about dynamic ports of SQL Server:
How to configure SQL Server Port on multiple instances?
When is a Dynamic Port “dynamic”?
When to use a TCP dynamic port and when TCP Port?
I got leads to solution of my problem from this blog.
in my case, i had a standalone server, i changed the sql server port default port 1433 in configuration manager to some number and restarted the sql serve service to take effect,i was able to connect to the sql server through management studio if i login to the server. but i was not able to connect from my local machine through sql server, i was getting the 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: Named Pipes Provider, error: 40 - Could not open a connection to SQL Server) (Microsoft SQL Server, Error: 5)
I checked and verified all the below
-Named pipes/TCP is enabled.
-Remote connections are allowed.
-Windows Firewall is off
-Created an exception for portin Windows Firewall( this was not necessary in my case as the server is in same subnet network).
-Enabled everything in SQL Server Configuration Manager.
then i chnaged back the port number to default 1433 and restarted the sql server service, and the issue got resolved and i am able to connect the sql server from my local management studio.
I had the same problem. I use the MSSQL Server Management Studio 2017 and solved this problem using these steps:
Check for working fine SQL Server Services services or not.
Also check for working in good condition SQL Server (MSSQLSERVER).
Also check for working fine SQL Server Browser.
Restart SQL Server (MSSQLSERVER)
and fixed it.
You will find most likely your DB name is not correct, you will see the server name in VS like "DESKTOP-0I14BKI" but if you open up SSMS you will see DESKTOP-0I14BKI\SQLBLAHBLAH , simply add "\SQLBLAHBLAH" (instance name) to your "server name" in VS connection properties.
You will see:
To Fix:
Try the following steps:
Open Services window (open "run box" and type services.msc).
Looking for SQL services (with SQL prefix).
Start them (if cannot start. Goto step 4).
Right_click to each service -> Properties -> Change to tab "Log on"-> choise log on as "Local ..." -> 0K. Then start SQL services again.
Try Open SQL and connect database.
In my case,
I opened SQL Server Management Studio and searched for SQLEXPRESS in my Database engine.
It had two instances and I selected the correct one.
If you are working with Asp.net core and using appsettings.json than write server as localhost and after write sql instance name for enabled named pipe like this
"ConnectionString": {
"dewDB": "server=localhost\\dewelopersql;database=dewdb;User ID=sa;password=XXXXX",
},
After following all the steps mentioned here, if it still does not connect, try adding the DNS with the IP address in the hosts file in the etc folder. Adding an IP address instead of DNS name in the connection string should be a temporary solution to check if the connection actually works.
I tried using the local IP address to connect as well as a public one.
I've tried:
Yes, the site can communicate with the server Named pipes/TCP is
enabled. Remote connections are allowed. Windows Firewall is off
Created an exception for port 1433 in Windows Firewall. Enabled
everything in SQL Server Configuration Manager.
i ensured and did the above as well and I just want to share that the DOUBLE BACKSLASH
oBuilder.DataSource = "SPECIFICPCNAME\SQLEXPRESS";
Using a SINGLE BACKSLASH resulted into a build error i.e.: Error 1 Unrecognized escape sequence
I hope this helps the next guy - I've sacrificed dinner, midnight snack and NBA highlights time solving this (shame)
Thanks to [Tamizh venthan]
^_^
Enable TCP/Ip , Piped Protocol by going to Computer Management ->SQL and Services, ensure the Service is On. Enbale the port on the Firewall. Try to login through Command Prompt -> as Admin; last the User Name
should be (local)\SQLEXPRESS. Hope this helps.
Open SQL Server Configuration Manager
Select SQL Server Services from right.
Find your server from right and go to its properties (with right click)
Change log on method to Local System.
I had the same problem and solved the problem by disabling my firewall(ESET).
The first step to solve this problem should be to try pinging your own computer from another computer. If you have firewall on, you may not be able to ping yourself. I tried pinging my own pc, then ping was failed(didnt get response from the server)
I was trying to add a new connection in VS2015. None of the suggestions here worked. Suspecting some sort of a bug in the wizard, especially since SSMS was able to connect just fine, I decided to try and trick it. It worked!
Instead of adding the connection, use "Create new SQL Server Database". Enter your server name and a random name for the new DB, e.g. "test".
Assuming this succeeds, open Server Explorer in VS, locate the connection in Data Connections, right-click it and select Modify Connection.
Change "test" (from step 1) to the name of the existing database you want to connect to. Click "Test Connection". This time it should work!
Delete the temporary database you created in step 1.
I have one more solution, I think.
I recently had changed my computer name so, after I couldn't connect still after trying all above methods.
I changed the Server name..
Server name => (browse for more) => under database engine, a new server was found same as computers new name.
This worked, and life is good again.
I struggled for ages on this one before I realized my error - I had used commas instead of semicolons in the connect string
I had this issue but none of the suggestions above fixed it.
I was seeing this issue when I deployed my website to IIS. The fix was to go into advanced settings against the default app pool and change the identity property from the default to Administrator.
For me it was a Firewall issue.
First you have to add the port (such as 1444 and maybe 1434) but also
C:\Program Files (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe
and
%ProgramFiles%\Microsoft SQL Server\MSSQL12.SQLEXPRESS\MSSQL\Binn\SQLAGENT.EXE
The second time I got this issue is when I came back to the firewall, the paths were not correct and I needed to update form 12 to 13! Simply clicking on browse in the Programs and Services tab helped to realise this.
Finally, try running the command
EXEC xp_readerrorlog 0,1,"could not register the Service Principal Name",Null
For me, it returned the error reason
I tried pretty much everything on this page but I had some underlying issues which were actually what needed to be resolved. I was unable to do certain things like open SQL Server Configuration Manager, which ended up being corrupt/missing WMI provider files.
There are lots of tedious ways to resolve this issues according to what I've read, but the tool from tweaking.com was able to remove and replace/repair my WMI (Windows Management Instrumentation) Provider files.
I used to do computer repair and overall the tweaking.com tool really impressed me, and it was suggested from one of the WMI error forum pages I went to.
After I fixed this issue I was able to connect to my SQL db, both locally and remotely.
Hope this helps someone.
open port number 1433 on your server for sql remote connection
If you tried restarting the MSSQLSERVER service, and it did not work, this might be a solution:
If you are using SQLExpress, your server name should be as the following ComputerName\SQLExpress. However, for SQLDeveloper, you do not have to right SQLDeveloper after your ComputerName.