On my family's main computer, my MS SQL Server login works fine, but on my laptop, I get an error when using the same login: https://i.stack.imgur.com/jpYSy.png
I've tried various solutions (enabling TCP/IP and Named Pipes, creating an inbound rule for TCP 1433 in firewall, making sure SQL Server Browser is running, etc.) but none of them have worked so far. I am able to log on my the local server on my laptop with no errors. to the If anyone could figure this out for me, I would really appreciate it.
(Keep in mind that I am relatively new to the server side of programming)
Based on the image you posted with your question, it appears that the login and/or password is incorrect. When you attempt to connect to the instance of SQL Server from your laptop, are you using the same SQL Server Login that you use on the "family computer"? It may be that at one time you saved the credentials on your laptop, and possibly the login and/or password has changed. Can you please verify the instance is the exact same, the login and the password are identical? Following that, you should either be able to connect, or will receive a different type of login error.
Are you trying to connect using the IP Address or the name of the server? If you are using the name of the server then try starting the SQL Server Browser service.
It appears that it cannot find that server, so just as a test turn the firewall off (momentarily) for the server and see if that is what is blocking you. If it is make sure that the firewall has a rule to allow the sqlserver.exe program to go through.
Thanks for the help, but it turns out that my antivirus was messing with my internet connection, and Firewall was blocking sqlserver.exe.
Related
Today I get this strange exception:
Error HRESULT E_FAIL has been returned from a call to a COM component. (mscorlib)
I cannot connect to my database! Tool started under admin rights.
Services:
I am not sure if disabling firewall is enough. if the user has sysadmin permissions and still getting this error means client is not able to connect to server in debugging mode. check this TCP and UDP ports are correctly open.
SQL remote debugging configuration
EDIT:1
I am sure you must have also googled a lot and tried to find out about the error messages. What I have found so far is the Error in the OP you mentioned is misleading and from that error, we cannot tell what exactly is wrong or what to look next. But as you replied in the comments, after making changes to enable Remote Debugger; the mentioned error is more clear and I feel that proper permission is still an issue. Plenty of other suggestion you also might have tried so far, but if you haven’t done this, let's try one more time:
In one of the comments, I mentioned you to try login using the windows user.
Now Keep the settings you already did for TCP ports, Firewall Exception etc… explained in the above link. you have windows 2012 server where you installed DB server. and windows 8 Prof where you have DB client and you connecting through SSMS. Now I believe both machines are in the same domain. Let’s say domain XYZ. You must have windows login on the server, let’s say it is “XYZ\HALI” using which you can login to the Windows Server. log in and make sure that login also exists in SQL SERVER with sysadmin permission. Because client machine is also in same domain make sure you have logged in into the client machine using same user “XYZ\HALI”. Now start SSMS and choose windows authentication instead of SQL SERVER authentication. Try to start Debugging T-SQL code now.
if client and server machines are not in same domain then we have to register server name on client machine as Linked Server, impersonate the login/user as local and then try the debugging.
Edit:2
Login to SSMS using Windows Authentication
I have read a number of articles on how to configure mirroring on SQL Server 2012. I went through the steps and everything worked until hitting the final step, which didn't work.
When I run this on the Principal:
ALTER DATABASE MyDBName SET PARTNER = 'TCP://1.2.3.4:5022';
I get this error:
The server network address "TCP://1.2.3.4:5022" can not be
reached or does not exist.
When I run the counterpart ALTER statement shown above, but on the Mirror, it works fine.
I have tried all the steps in this troubleshooting article.
Important points:
The Primary and Mirror servers are in different datacenters, not on the same network at all. Not connected by VPN. Completely untrusted by each other.
I can connect to the Mirror via SSMS on the Primary and run queries. And vice versa.
I configured certificates on each server to establish the trust relationship. Everything worked during the setup and config, no errors.
I configured the endpoints on both servers and verified they're active/enabled.
I opened port 5022 on both servers by configuring incoming and outgoing windows firewall rules. I can telnet to the Mirror from the Principal and vice versa - ports appear open, no problems.
In the troubleshooting guide mentioned above, I tried steps 1-6. I didn't try 7, deleting the endpoints and re-creating, because they look perfectly valid and active to me.
Looking for some ideas on this one.
If you can telnet that port from the principal machine everything is fine with TCP/IP and firewall settings.
I can remember that I had a similar issue in the past. Unfortunatly I dont remember the exact solution but it was related to security/authentication of the endpoints and the SQL Server service account not having enough permission on the mirror machine. Unfortunatly the error message is pretty misleading in this case. Script the endpoints and verify their settings, SSMS has no UI for that.
Another thing that you could check is that you have the possibility to also connect to port 5022 from the mirror to the principal machine. You will get the same error message if the connection is not possible from both instances.
Sorry that I cant provide you a proper solution, but maybe that points you to the right direction.
Unfortunately there are quite non-informative error messages in MS SQL. The problem might be an authorization issue and the server still will be saying "network address can not be reached".
Considering "servers are in different datacenters", how the authentication is performed? A MSSQL service (on server1) itself must be runned as a valid db user (on server2, and vice versa) in order to make the mirroring work.
There can be multiple reasons for this to happen.
In your SQL Server Management Studio, if you see a White bubble next to the server instance name, instead of the Green bubble, then you can try the following:
"Allow an app through firewall" and add "Windows Management Instrumentation (WMI)" for Windows Server 2012. If it is Windows Server 2008, you can allow "Remote Administration" through firewall.
Is it meant to be a semi colon?
ALTER DATABASE MyDBName SET PARTNER = 'TCP://1.2.3.4;5022'
The semi colon is used when connecting to IP / Port when using management studio.
Hi all I installed SQL Server and from the localhost it works in my project however when I tried to access database from another computer It gives 0x80131904 exception. I couldn't find the reason what might be the solution?
Have you tried connecting by specifying the port number as well? Something like,
YourServerName,1433
YourServerName\YourInstanceName,1433
I have assumed it is on the default port. If not change 1433 with appropriate port number and try it.
Make sure your server is enabled for tcp/ip connections and that your computer does not block the SQL server port. Also make sure that you enable the proper authentication methods, ie SQL server auth, integrated, etc.
I'm using SQL server 2008r2 on a windows 2003 server and connecting to it from a vista machine.
The database itself is part of an application that uses ODBC to connect and that connects perfectly 100% of the time.
But as I'm making some changes to the application and database I'm working through the management console. The first time I try and connect to the db in the morning it times out.
I have a work around for it that involves remote desktoping to the server and connecting to the db using the mamangement console on the same server. Once I have connected locally I can close the remote session and then I'll be able to connect to the server from the management console on my pc. This connection will stay open all day but if I close the management console for a while (10+ mins, I havent fully tested how long) it will timeout again.
This happens from other client pcs as well so I'm thinking that I need to change something on the server... does anyone have any pointers as to what settings could cause this login timeout? and what I can do to fix it as its becoming a serious annoyance!
It sounds like you need to enable TCP/IP protocol. You can do this via SSCM (SQL Server Configuration Manager).
I think I have got it figured out now. The solution that seems to work is linked to TCP/IP protocol, as the above poster mentions. I needed to go into the protocol and update the ports used from dynamic to fixed and put them on 1433 (why this isn't default I dont know, and I presume theres good reason for it!)
Answer found on the post below
https://serverfault.com/questions/179898/sql-server-timeout-on-first-attempt
I have a desktop, and a Laptop. The Desktop has Windows 7 64-bit and the Laptop has Vista Ultimate 32-bit. On both machines I have SQL Server 2008 Standard installed.
On the laptop, I open SQL Management Studio and try to connect to the SQL Server on the desktop. It times out.
With SQL Server Config Manager I Enabled TCP/IP and Named Pipes for the client protocols.
In SQL Management Studio, I right clicked on the Database Engine, went to properties, and allowed remote connections. I also created a sql server login named "testuser" and a password. I then added that user as a login for my database and made them the database owner.
I could not figure out how to allow connection to my db throw the windows firewall, so I turned it off.
What am I missing? I made the same changes on my laptop, and I can connect from the Desktop to the Laptop in Management Studio?
Do you have a checklist?
Thanks.
UPDATE:
I turned off antivirus. Ran NetStat -a and the listener is listening.
If your login attempt takes about 30 seconds to timeout, then it's some kind of network connectivity problem (or SQL isn't listening properly). A permissions problem would come back after a few seconds, so the long wait says it's connection-related.
If you run "NETSTAT -a" on the server, so you see SQL Server listening on port 1433? If not, then maybe the SQL TCP Listener isn't configured properly on the server - there should be events in the Windows Event log to this effect when the SQL Service starts up.
Please edit your question with the results and we can go from there.
Try using Telnet to see if the laptop can see the desktop via port 1433.
Open a command prompt on the laptop and enter:
telnet DesktopNameOrIPAddress 1433
Press Enter, and you should either see a connection failed error, or a blank screen. If you get the blank screen, the connection was established. Press CTRL-] to break out of it, then type "quit" and enter to quit.
If the connection failed, attempt to resolve the general network issue with port 1433 before bothering to use the SQL Server tools.
If you have any other anti-virus software running, it may also have a firewall built in. I know that McAfee does, for instance. Check for that.
You've probably already thought of this, but have you checked that the server is configured to allow Mixed Mode Authentication? I have not had access to 2008, but I seem to remember that at least one of the previous versions was configured to disallow sql logins by default.
I assume you already did what you have to do on the OS level. Or maybe tried to link the server to see if you can actually traverse your network. Let me suggest a quick test. Check if you can actually test connectivity by creating a Universal Data Link. In case you don't know how to do this, create a new text file in your desktop (or anywhere) and change the .txt file extension to .udl; then just open it. See if your other server is "viewable" over the network (Don't forget to change the Provider to OLE DB Provider for SQL Server).
Is the SQL Browser Service running on the server you are trying to access? (By default this is disabled, and you'll need that to access SQL Server remotely)