Easy way to check connectivity to SQL Server from client

  • For troubleshooting purposes, I would like to be able to check if a client can connect to a SQL Server instance, independent of the application that possibly can't connect to the SQL Server.

    Is there an easy way (that means, not having to install 3rd party software) to do this using the default Windows system tools? Perhaps using scripts or network applications?

    on my notebook i can create a sqlserver odbc connection and test access to the sqlserver. But I don't no if the sqlserver odc driver can be found on all clients that are configured to access sqlserver. but if it could be found this would be the next test after checking the reachiility of the server's sqlserver prot with telnet.

  • db2

    db2 Correct answer

    8 years ago

    If the server is using TCP/IP, then the simple way is to just telnet to the SQL Server port and see if it connects. By default, that's port 1433, so this should work:

    telnet servername 1433

    That will probably be appropriate in most cases.

    If it's using a different port, or dynamic ports (common with a named instance), then you'll need to determine which port it's currently listening on. Check SQL Server configuration manager to see if it's a specific port, or dynamic ports. If it's using dynamic ports, then as long as you don't have multiple instances on the server, netstat -abn is probably the simplest way to find what it's using. Otherwise, dig through the Windows event log or the SQL Server error log for a message indicating which port is in use by the instance.

    If SQL Server is using Named Pipes, then I believe if you're able to access shares on the machine, you have adequate network connectivity. This article says you can go further and try connecting to the IPC$ share:


    net use \\servername\IPC$

    That's written for SQL Server 2000, but I don't imagine this aspect has changed much, if at all.

    That's not seeing if a client can "connect to a SQL Server instance". That's just testing to see if a port is listening.

    ...which is seeing if a client system "can connect to a SQL Server instance, independent of the application that possibly can't connect to the SQL Server." Anything beyond the network connectivity is dealing with application issues.

  • A simple test method for SQL connectivity is to create an empty text file, with a file extension of "UDL". You can create it in Notepad. And it can have any name. I use "TestSQL.UDL"

    Save it on the desktop of a windows PC and double click it.

    A "Data Link Properties" dialog box will pop up where you can enter the IP address of the SQL server and also a SQL username and password.

    Click the "Test Connection" button to see if you can connect.

    enter image description here

    Be sure to click the Provider tab and select the right OLE DB provider:"Microsoft OLE DB Provider for SQL Server"

    Dave, welcome, and good answer. You can edit your post (lower-left corner) to add this additional information. Then delete your comment.

    This really is a great answer because it works on pretty much any server regardless of what or what isn't installed. All you need is Notepad. Thanks for this great answer, really helped me convince my client that SQL connectivity was working.

    I agree with @robnick - this answer was so helpful in helping me fix an issue I was having. Thanks!

  • Provided you have the Microsoft.SqlServer.Smo assembly in your GAC on the local machine, this can be easily done with PowerShell:

    [Reflection.Assembly]::LoadWithPartialName('Microsoft.SqlServer.Smo') | Out-Null
    $server = New-Object Microsoft.SqlServer.Management.Smo.Server("YourSqlServerName")
    # do a simple operation to see if you can get data
    Try {
        $server.Version | Out-Null
        Write-Host "SQL Server connection successful!!!"
    Catch [System.Exception] {
        Write-Host "Error connecting to SQL Server..."

License under CC-BY-SA with attribution

Content dated before 6/26/2020 9:53 AM