This is the short version, the longer version is further down, also make sure and review the SQL Express BOL and the Mini BOL.

Follow these steps:

1. Make sure express is running correctly (assumes a default install)

 Drop to a cmd prompt

 Type the following

        sqlcmd -S.\sqlexpress

 You should get a prompt like this

        1>

 Type

        Exit

 to exit sqlcmd


2. Enable Protocols

     a. Launch SQL Computer Manager

     b. Expand "Server Network Configuration"

     c. Expand Protocols for "SQLEXPRESS"

     d. Enable Np (for local and remote access)

     e. Enable TCP (for local and remote access)

3. Restart SQL Express

     a. can be done from either SQL Computer Manager, Services applet, or command line( net start mssql$sqlexpress)

4. Start SQL Browser service from Service applet or command line( net start sqlbrowser)

At this point the client should be able to connect, if the machine is rebooted then the last step (4) needs to be repeated as this service must always be running. You can also set this service to autostart via Computer Manager, Services Management Applet.

These actions need to be performed wherever the machine is that has SQL Server Express running on it. If machine A is running SQL Express and an attempt is made to connect from a local tool or applet the steps must be performed on machine A. If an attempt is made to connect from a different machine(B) then the steps still need to be performed on Machine A.

-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

The long version.

This entry is designed to help explain the reasons behind the steps in the short version of this post. Lets walk through the steps and the problems and try and explain whats happening

Checking to make sure that Express is running via SQLCMD

The default install for SQL Express installs Express as a named instance(called SQLExpress), with no network listening and with Windows Authentication support only.

To connect to a named instance of SQL Server the convention is to use a servername of the format <servername>\<instancename>, its also possible to shortcut the machinename to either "." or "(local)"(these shortcuts work with all protocols, localhost will also work but only with TCP/IP in older clients,however SQL Native Access supports resolution of LocalHost for Named Pipes and Shared Memory).

No user id and password has been specified because of the default windows authentication, if the install had been changed to specify mixed mode authentication and a password had been given then this could have been used.

Enabling Protocols

Because SQL Server Express does not listen on the network by default connections are made using a local protocol, in the case of the VS 2005 SKUs this is the shared memory protocol. The interface to this has changed in SQL Server 2005 such that older clients can no longer use it. Hence for older clients to work a different local protocol or a network protocol must be used, these are not enabled by default and must be manually enabled.

SQL Browser Service

In general when a client connects remotely to a SQL Server named instance the client does not know the port that the instance is listening on(you can work around this by configuring SQL Server named instances to listen on a specific port and then specifying that port in the connection string in the format <servername>,<port number>)

So when an application attempts to connect to a named instance in the form <servername>\<instancename> the client connection needs to be directed to the correct port. In SQL Server 2000 one of the running services had a built in listener that received the named instance connection requests and redirected them appropriately.

In SQL Server 2005 this functionality has been moved to a dedicated listener service, that service is SQLBrowser.

SQLBrowser also performs another service, that of SQL Server Discovery, its common in many UIs from Microsoft and others to have the ability to browse for instances of SQL Server running locally or remotely, again in SQL Server 2000 this was handled by one of the running instances of SQL Server, in SQL Server 2005 this is handled by the SQLBrowser Service.

Thus the SQLBrowser Service must be started to be able to discover any instance on the machine, and also to connect to named instances through protocols other than shared memory. If network protocols are not enabled via the setup switch then the browser service is not set to autostart.

SQL Native Client

SQL Server native connectivity is defined as connectivity through OLE DB(ADO uses OLE DB under the covers) or ODBC means in SQL Server 2005 (dblib is not an included as a data access technology in SQL Server 2005).

In previous releases of SQL Server(SQL7 and SQL2000) an update to MDAC was preferred for client apps, this means the installation of an entire MDAC update for SQL Server connectivity. In SQL Server 2005 we no longer require an MDAC update as we have refactored out the SQL Server specific connectivity components for OLE DB and ODBC.

As such in SQL Server 2005 no MDAC update is required to connect(although MDAC 2.8 is preferred, any MDAC from Windows 2000 SP3 upwards is supported), but a new component is required. This component is referred to as SQL Native Access.

These components include support for OLE DB and ODBC accessed through a single .dll called: SQLNCLI.dll, this file and its support  files are redistributable.

SQL Native Client is NOT required for managed data access via .Net APIs.

 

-Euan Garden

Product Unit Manager

SQL Server Tools