I'm attempting to remotely connect to my SQL Express 2016 server through MS SQL on my local machine however am having extreme difficulties with the authentication.. Well I assume it is an authentication issue as when I attempt connect to connect to it I receive the error message:
The remote computer refused the network connection.
When connecting through the sqlcmd I am using Windows authentication and have no issue, however to connect to it remotely I need to use SQL authentication and have no memory of creating an account so am wondering if there's a default login and password?
I believe this is the issue however it is quite likely i'm doing something stupid so any assistance would be appreciated!
You can create an account that can be used to connect to that SQLExpress instance by using SQL Server Management Studio. Expand the database you wish to create a login for in the Object Explorer. Under the Security folder, you can create a new login by right clicking the Logins folder.
Also make sure that your machine has its firewall configured to allow remote connections, the server has remote connections enabled, and that you are allowing logins for Windows Auth and SQL Server Auth.
You can allow remote connections for a server by opening the SQL Server Configuration Manager. Under the SQL Server Network Confiuration Node, Select Protocols for MYSERVERNAME. Ensure that TCP/IP is enabled.
Here's a guide on setting up the firewall: https://technet.microsoft.com/en-us/library/ms175043(v=sql.110).aspx
You can enable SQL Server Authentication by right clicking your server name in the object explorer in SQL Server Management Studio and going to the Security tab. look for the "Server Authentication" option.
In an attempt to do some basic profiling on our Azure SQL Server (V12) we enabled Auditing using the Azure portal.
Not many seconds later I had an angry developer on my hands that could not connect to the database using his client (HTML5 page).
I really couldn't see the connection, but since enabling auditing was the only change, I tried disabling Auditing again, and sure enough now the client could connect.
Further info:
I could access the SQL server using SSMS just fine.
The problem was only on the TEST environment from the customers network, not from our DEV environments (which is from Visual Studio on the developers own laptops).
Can anyone tell me why enabling auditing can break this? We tried doing it on other databases too, and sure enough: when I enabled auditing, the connection could not be established...
According to this page, if you want auditing on, the FQDN connection strings need to be changed:
Original server FQDN in the connection string: (server name).database.windows.net
Modified server FQDN in the connection string: (server name).database.secure.windows.net
I installed SQL Server Management Studio on my machine and once it was succesfully installed, I tried to connect to the local Database Engine but I was not succesful connecting to it it showing up an error showing as Cannot connect to the Local or having Network Related problems in the connection. I got a question here once I download the SQL Server management studio Do I need to do something else to get connected to the Local SQL Server.
Thanks,
Pranay.
No you don't need by default you can connect to local machine. You might have a problem connecting from other machine in the network if TCP is not enabled, but local should work.
Make sure you typed your 'sa' password correctly or use Windows Authentication.
Did you check in Windows Services? There is the service SQL Server (SQLEXPRESS) and SQL Server Browser which must be running.
Go to your Sql Server Configuration Manager and make sure that SQL Server is running. Otherwise right click and click Start.
And sometimes you need to Enable TCP/IP in your Protocols again in your Sql Server Configuration Manager
I’m trying to access the SQL Server instance on my VPS from SQL Server Management Studio on my local machine. It’s not working (the error I’m getting is:
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.
I think this is because I need to configure the database engine to allow remote connections (correct me if I’m wrong!). So I’ve found this step-by-step guide to help me do that: http://www.linglom.com/2009/03/28/enable-remote-connection-on-sql-server-2008-express/ I’ve got to point 10 in the guide and I am now stuck! I don’t have SQL Server Management Studio installed on my VPS. Anyway, this has left me with two options:
Install SSMS
Find another way to do point 10 onwards in the guide without having SSMS installed
I tried installing SSMS on my VPS using the Web Platform Installer but it keeps failing. I don’t know why it’s failing because it doesn’t seem to give a reason why. Does anyone know how I could allow remote connections a different way?
The version of SQL Server installed on my VPS is SQL Server 2008 R2 Express.
Update:
I have tried to disable the firewall on both my laptop and VPS to see if it is a firewall issue. This made no difference to the error message.
Another Update:
Having now been able to install SSMS (I installed directly from the website rather than using the WPI), I have been able to check that the server is configured to allow remote connections (I went to SSMS, connected to the SQL Server instance, right-clicked on the connection, clicked Properties, went to the Connections tab. "Allow remote connections to this server" is already ticked).
SOLUTION
Thanks to everyone for helping me get to this solution! I've finally managed to get it to work! I followed Filip De Vos's advice and opened the ports in the Firewall on my VPS and then I received a different error message. This led me to investigate further and I found that I was using the wrong credentials to login! So I've set a password for the sa user and I've managed to login using that! Thanks again!
To enable mixed authentication you can change the following registry key:
HKLM\Software\Microsoft\Microsoft SQL Server\MSSQL.1\MSSQLServer\LoginMode
Update the value to 2 and restart the Sql Server service to allow mixed authentication. Note that MSSQL.1 might need to be updated to reflect the number of the SQL Server Instance you are attempting to change.
A reason for connection errors can be a virus scanner installed on the server which blocks sqlserver.exe.
Another reason can be that the SQL Server Browser service is not running. When this service is not running you cannot connect on named instances (when they are using dynamic ports).
It is also possible that Sql Server is not setup to listen to TCP connections and only allows named pipes.
In the Start Menu, open Programs > Microsoft SQL Server 2008 >
Configuration Tools > SQL Server Surface Area Configuration
In the Surface Area Configuration utility, click the link "SQL Server
Configuration Manager"
Expand "SQL Server Network Configuration" and
select Protocols.
Enable TCP/IP. If you need Named Pipes, then you can
enable them here as well.
Last but not least, the Windows firewall needs to allow connections to SQL Server
Add an exception for sqlserver.exe when you use the "Dynamic Port" system.
Otherwise you can put exceptions for the SQL Server ports (default port 1433)
Also add an exception for the SQL Server Browser. (udp port 1434)
More information:
How to: Configure a Windows Firewall for Database Engine Access
Server Connectivity How-to Topics (Database Engine)
As a last note, SqlLocalDB only supports named pipes, so you can not connect to it over the network.
In addition to configuring the SQL Server Browser service in Services.msc to Automatic, and starting the service, I had to enable TCP/IP in: SQL Server Configuration Manager | SQL Server Network Configuration | Protocols for [INSTANCE NAME] | TCP/IP
Launch SQL Server Configuration Manager on your VPS.
Take a look at the SQL Server Network Configuration. Make sure that TCP/IP is enabled.
Next look at SQL Server Services. Make sure that SQL Server Browser is running.
Restart the service for your instance of SQL Server.
Open the SQL Server Configuration Manager....
2.Check wheather TCP and UDP are running or not....
3.If not running , Please enable them and also check the SQL Server Browser is running or not.If not running turn it on.....
Next you have to check which ports TCP and UDP is using. You have to open those ports from your windows firewall.....
5.Click here to see the steps to open a specific port in windows firewall....
Now SQL Server is ready to access over LAN.......
If you wan to access it remotely (over internet) , you have to do another job that is 'Port Forwarding'. You have open the ports TCP and UDP is using in SQL Server on your router. Now the configuration of routers are different. If you give me the details of your router (i. e name of the company and version ) , I can show you the steps how to forward a specific port.
I had the same issue where my firewall was configured properly, TCP/IP was enabled in SQL Server Configuration Manager but I still could not access my SQL database from outside the computer hosting it. I found the solution was SQL Server Browser was disabled by default in Services (and no option was available to enable it in SQL Server Configuration Manager).
I enabled it by Control Panel > Administrative Tools > Services then double click on SQL Server Browser. In the General tab set the startup type to Automatic using the drop down list. Then go back into SQL Server Configuration Manager and check that the SQL Server Browser is enabled. Hope this helps.
Disable the firewall and try to connect.
If that works, then enable the firewall and
Windows Defender Firewall -> Advanced Settings -> Inbound Rules(Right Click) -> New Rules -> Port -> Allow Port 1433 (Public and Private) -> Add
Do the same for Outbound Rules.
Then Try again.
I recently upgraded from SQL 2008 R2 to SQL 2012 and had a similar issue. The problem was the firewall, but more specifically the firewall rule for SQL SERVER. The custom rule was pointed to the prior version of SQL Server. Try this, open Windows Firewall>Advanced setting. Find the SQL Server Rule (it may have a custom name). Right-Click and go to properties, then Programs and Services Tab. If Programs-This program is selected, you should browse for the proper version of sqlserver.exe.
If you have more than one Instances... Then make sure the PORT Numbers of all Instances are Unique and no one's PORT Number is 1433 except Default One...
Open SQL Server Configuration Manager.
Click SQL Server Services, on the right side choose the server you've created during installation (by default its state is stopped), click once on it and a play button should appear on the toolbar. Click on this play button, wait til its state turns to "Running". Now you're good.
Open SQL Server Management Studio; switch the "Server Type" to "Database Engine" and "Authentication" to "SQL Server Authentication". The default login is "sa", and the password is the password that you chose on creating the server. Now you're good to work.
In my case the problem was caused by the inconsistency between computer names. In system settings my computer was named with some long name, but apparently the name used for some certain communications was trimmed.
I changed the name in the settings to a shorter one and it worked.
I had built both a console app and a UWP app and my console connected fine, but not my UWP. After hours of banging my head against the desk - if it's a intranet server hosting the SQL database you must enable "Private Networks (Client & Server)". It's under Package.appxmanifest and the Capabilities tab.Screenshot
Before download the last version and update your sql server to fix errors of TLS 1.2 on Sql Server 2012. For more information, check here.
Our MS Access application with linked tables to SQL Server 2005 is slow when using Windows Authentication from Windows XP clients.
We've been running it successfully using SQL Server authentication, but now we want to move to Windows Authentication for better security control.
Setup:
Database server: Windows 2003 Server, SQL Server 2005 SP2
Client: Windows XP SP3, SQL Server ODBC driver v2000.85.1132.00
MS Access application: MS Access 2003
Connection string:
DRIVER=SQL Server;SERVER=[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Only the TCP/IP network protocol is enabled on the server.
The slowness does not happen in these situations:
App on DB server, SQL Server Authentication
App on DB server, Windows Authentication
App on Windows XP client, SQL Server Authentication
SQL Server Management Studio on client, Windows Authentication - I did a small test with running 15 queries in SQL MS. This went fast and did not cause any logon/logoff events in the Security event log on the server.
I've analyzed the slowness using SQL Server Profiler and the event log on the server and it seems to come down to this:
The application runs a query
A new connection to SQL Server is opened (visible in SQL Server Profiler)
The identity of the user is verified (visible in the Security event log on the server, a logon/logoff event happens). This takes several hundreds of milliseconds.
The query runs on SQL Server
Results are returned to Access
This happens for every query. Some of the forms run +- 10 queries when showing a new record (updating sub forms, loading values for combo's etc). This results in very slow performance.
Of course setting up a new connection to SQL Server for every query isn't necessary, and reusing connections might solve the issue. I've been looking around for information on how to make sure Access/ODBC does proper connection pooling. I found these MS KB articles:
Frequently Asked Questions About ODBC Connection Pooling
How to Enable Connection Pooling in an ODBC Application
I've tried calling the SQLSetEnvAttr function from the main form of the Access application, but this didn't improve results.
Any help is greatly appreciated.
The first question I have is: are you running a domain controller? This may sound like a crazy question, but I just want to make sure. Although is less and less common, I've seen organizations run Windows networks with workgroups and "pass-through" authentication. The symptoms you describe are the same as would be observed on a network that is set up in this fashion.
Assuming you do have a proper domain set up, you must have a problem somewhere in the Named Pipes network stack. Named Pipes is the default protocol if you're using Windows authentication. It's not a bad idea to get to the bottom of this if you have the time, but if you just want to fix your performance problem, then I would force the TCP/IP protocol in your connection string:
DRIVER=SQL Server;SERVER=tcp:[server name];Connect Timeout=300;Trusted Connection=True;APP=Microsoft Office 2003;WSID=[server name];DATABASE=[db name]
Note the addition of the tcp: prefix. I got this syntax from Jon Galloway's blog. TCP/IP is the default protocol for SQL Server Authentication. You can also make the protocol switch by disabling Named Pipes support on the server, but this is more of a hassle and could cause other unanticipated problems.
Check Microsoft SQL Server Native Client
at http://www.microsoft.com/downloads/details.aspx?FamilyID=d09c1d60-a13c-4479-9b91-9e8b9d835cdc&displaylang=en