Each member of our development team has a copy of our application's database running on a local version of SQL Server 2008 Enterprise with SP1. Everyone is able to access the database by specifying their server and instance name in their web.config file, but to best share the developer version of our web.config file, we have standardized on making connections strings generic by using integrated security and setting server property to (local). This strategy is working fine for the majority of our 64-bit Windows 7 machines but in few cases (local) isn't recognized. We have compared settings via the SQL Server Configuration Manager (namely ensuring that the named pipes protocol was enabled) and we've tried setting the "(local)" alias via SQL Server Client Network Utility, but we haven't any luck. What needs to be done in order to use (local) in our connections strings?
Trying changing the Pipe Name for your instance to "\.\pipe\sql\query".
You can find that setting by starting SQL Server Configuration Manager, and navigating to SQL Server Network Configuration > Protocols for (Instance Name) and right-clicking on Named Pipes and selecting Properties. If Named Pipes is not enabled, be sure to enable it before restarting the SQL Server service (see comment by #NoahHeldman).
When connecting to the default instance (that is, without an instance name), SQL Server uses the default port of 1433 and the default pipe name of "\.\pipe\sql\query". Changing it back to match should (hopefully) fix it.
Those machines where the database connection as (local) doesn't work is probably that way because during the database installation, the instance name was set to something specific, rather than the default of "default instance". You can change these instance names, which may resolve this issue: http://coderjournal.com/2008/02/how-to-change-instance-name-of-sql-server/.
I think this occurs when you have SQL Server Express already installed and running, and then install SQL Server Developer Edition / Standard / etc....not 100% sure though, but from what I recall, that may be the case.
Related
I don't seem to be able to connect to a locally installed SQL Server 2019 instance using DataGrip (2019.3).
No matter which auth I use (domain or SQL), I get the following error:
"The specified database user/password combination is rejected: [08S01] The server SQL19 is not configured to listen with TCP/IP"
URL I'm connecting to is jdbc:sqlserver://localhost\SQL19.
If instead of "SQL19" part I use SQL Server 2016 instance name, it works fine,
so I'm assuming I'm configuring the connection correctly, unless there's some tweaks I need for SQL 2019?
I can connect to a 2019 instance from SSMS and applications, it's available via TCP/IP etc.
Answering my own question with some details (#moscas answer is correct, but I feel details may still be useful for somebody).
TCP/IP seems to be disabled by default in SQL Server 2019, and SQL Configuration Manager turned out to be not easy to find: it doesn't show up when you do regular search in "Start" menu and it doesn't exist under SQL Server's folder in the menu (wtf, Microsoft?).
You need to go Computer Management (this does show up in search) -> Services and Application -> SQL Server Configuration Manager -> SQL Server Network Configuration, choose your instance and enable TCP/IP.
Datagrip starts to work then.
As far as I know, SSMS does not require TCP/IP, that's why it works. For DataGrip, you need to turn it on.
Perhaps this doc will help: https://www.jetbrains.com/help/datagrip/db-tutorial-connecting-to-ms-sql-server.html
In additional to enable TCP/IP in SQL Server Configuration Manager. I also had to enable the Sql Browser service under Sql Service Service.
I have a small application that uses a SQL-Server express 2005 database located on a remote machine. This has worked for years. I've not only been able to access it via the application, but also on the development machine. The other day I came in to the server (windows 7 machine) shut down from a power outage. Since then I have not been able to access the database and receive an error 26. I have checked the firewall and it does indeed have the exception for sqlbrowser and UDP 1434 set. I also checked Configuration Manager and SQL Server (SQLEXPRESS) and SQL Server Browser are both running. (Even did a restart on both)
Client Protocols are enabled for Shared Memory, TCP/IP and Named Pipes.
Here is where it gets strange (At least for me). Both the development machine and the machine that uses the application that works with the database were both set to Obtain IP Address. If I set these to a static address they are then able to access the database without issues. I would like to not have to set static IP's and get things running the way they have for the past couple of years. Does this shed any light on what I might need to check to see why I can no longer access this server without a static IP on the remote machines?
The server is 2007 pro along with the development machine. The remote machine that uses the application is Windows 10 pro.
I should also state that I can browse the network and access normal shares via windows network with and without the static ip from both machines.
EDIT: The exact message I get when I don't use a static ip 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. (provider: SQL Network Interfaces, error: 26 - Error Locating Server/Instance Specified) (Microsoft SQL Server)
I get this error even when trying to connect using Microsoft SQL Server Management Studio Express.
After many installations I learned that opening the SQL Server port in the firewall works always when using the default instance, but with named instances and SQL Browser opening the ports some times doesn't prevent the firewall for blocking connections, specially in small environments that doesn't have a proper server like the one you describe (I think that it's related to the dynamic port feature that SQL Server use by default with named instances, but I'm not sure).
When I have to use named instances instead of opening the ports I create rules for the programs themselves and it has worked fine until now. Create two rules using New rule > Programs > This program path, one for:
C:\Program Files\Microsoft SQL Server\90\Shared\sqlbrowser.exe
and other for:
C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn\sqlservr.exe (maybe this location is a bit different when using the SQLEXPRESS instance).
I usually create the rules only for private network locations, but maybe you should create the rules for all locations just to be sure (and if this works, try unchecking public locations from the rules).
For future installations note that you can configure Express editions to use the default instance MSSQLSERVER at install time (and only at install time), with that option you just open port 1433 and you are done.
I am facing server name problem in SQL Server 2012. When I click on configure distribution I get an error:
Unable to connect to server. Specify the actual server name.
I changed my server name and restarted the services but unable to connect through new server name.
Basically, I am doing this on local domain based server.
Kindly suggest a suitable solutions.
After you rename a SQL Server machine, you will also need to rename the SQL Server instance itself using:
sp_dropserver <old_name>;
GO
sp_addserver <new_name>, local;
GO
For more information, see Microsoft's article called Rename a Computer that Hosts a Stand-Alone Instance of SQL Server.
I think what your probably finding is that changing the Windows server hostname doesn't actually change the original SQL Server instance name which still gets used for certain services. Run the following on the DB engine:
SELECT ##SERVERNAME
You'll probably find a different value to what your expecting from the OS.
There isn't really a solution to this that I'm aware of without re-installing SQL Server on the newly named box.
Also be careful with names that exceed to the 15 character NetBIOS limit.
Can someone explain why after installation of SQL Server some PC get a suffix of \SQLEXPRESS and some don't? Is there an option to change it?
Any suggestions or tips would be appreciated.
That is the SQL Server instance name for the new SQL Server you installed. A single machine can host multiple instances of SQL Server. The naming convention you see: hostname\instance_name is used to identify the different SQL Server instances running on a single machine.
When you install SQL Server Express, the default instance name created is SQLEXPRESS.
See:
Default instance name of SQL Server Express
How to: Identify a SQL Server Express Instance
Instance Configuration
The hostname is used for machine to machine networking. That is the same name that is used for Netbios/SMB file sharing services (\\hostname) and normally resolved for TCP/IP services through DNS (http://hostname).
The hostname\instance_name is purely a SQL server naming convention. Its only purpose is to identify a running instance of SQL server. The SQL server client network libraries know how to resolve these instance names. The standard network stacks do not. This means the following do not work:
ping hostname\instance_name
\hostname\instance_name
http://hostname\instance_name
The \instance_name only works with SQL server network clients.
We've been experiencing a strange issue with SQL 2008 R2 (10.50.1600) installed as a named instance. In order for any external clients to connect, we have a certain procedure we have to follow, but should not have to. Now I did in fact open the TCP/IP and Named Pipes protocols on the SQL server and restarted it, this isn't the problem. We're on an Active Directory Domain (running from Server 2003). The problem exists no matter what OS the server or client is (XP, 2003, 2008, Vista, 7, 64bit, 32bit, etc.). The problem also persists from anything which can connect, for example, SQL Management Studio, ADO (from our applications), etc.
The problem is that before any client can connect to this server, each client machine must first connect to this server through ODBC (and we don't use ODBC). Any attempt to connect to a 10.5 SQL server before doing this results in "Server does not exist or access denied". But once we can connect in the ODBC (through Named Pipes), then everything else starts to work. The same issue occurs both when using the Computer Name and IP Address. In fact, if we want to connect with computer name \ instance name, then we have to do so first in the ODBC, and then if we want to connect via the IP address \ instance name, then we have to do the same also for that.
We've been having to do this on every single client computer. Again, once the ODBC is able to connect to this SQL server through Named Pipes, then all future attempts from that client work.
What could be causing this to occur? How to avoid it? I should not have to do this "ODBC Trick" as we've been calling it. I've never had this issue on any other version of SQL.
The issue might be related to the SQL Browser service. Each sql instance will have a different port number - try connecting from the client as IP Address,Port (e.g. 123.123.123.1,1433) - this will exclude DNS and Browser from the equation
Edit: now knowing that it is browser related, try see why clients can't access SQL Browser (usually Port 1434). Service not started? Possibly firewall blocking?
Microsoft have tied down everything security wise now by default, so any new configuration now generally requires quite a bit of detailed security planning, policy configuration, permissions etc. Welcome to the age of non-trust ;)
You could easily test your connection by creating a simple file. Follow the steps here at "How to test an SQL Server connection": http://teusje.wordpress.com/2012/02/21/how-to-test-an-sql-server-connection/