Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Client Configuration
Thus far, this chapter has discussed the server configuration. Now it's time to take a look at the client side.
Client/Server Architecture
SQL Server is a client/server database management system. That means that client processes, which are often running on remote machines, must communicate with SQL Server over the network, as shown in Figure 3.9.
){kind=link}
Figure 3.9 Client/server architecture.
Client processes communicate with SQL Server in the following ways:
Open Database Connectivity (ODBC). This is a native SQL Server driver used by many applications and developer tools including Visual Basic and Visual C++. The Data Access Objects (DAO), Remote Data Objects (RDO), and Microsoft foundation classes (MFC) all use ODBC.
OLE DB. This is also a native SQL Server provider based on the Component Object Model (COM) and the Distributed Component Object Model (DCOM). It is less widely supported today, but support for it is expected to grow. It can be used from Visual Basic and Visual C++ as well as Visual Interdev. The ActiveX Data Objects (ADO) use OLE DB.
DB-Library (dblib). This is the original application programmer's interface (API) to SQL Server. It is supported for backward compatibility, but has not been enhanced with SQL Server 7.0 features.
Regardless of which of these is being used, the communication process is identical, as Figure 3.10 shows.
){kind=link}
Figure 3.10 Client/server communications.
What's important is the network library. Chapter 2 discussed choosing network libraries for your server. It is important that the library each client is using match one on which the SQL Server is listening. Otherwise, there will be no communication.
The client and server network libraries are DLLs. The relationship between the netlib and the actual DLL is shown in the following table.
|
Netlib |
32-bit DLL |
16-bit DLL |
|
multiprotocol |
DBMSRPCN.DLL |
DBMSRPC3.DLL |
|
named pipes |
DBNMPNTW.DLL |
DBNMP3.DLL |
|
TCP/IP Sockets |
DBMSSOCN.DLL |
DBMSSOC3.DLL |
|
IPX/SPX |
DBMSSPXN.DLL |
DBMSSPX3.DLL |
|
AppleTalk |
DBMSADSN.DLL |
n/a |
|
Banyan VINES |
DBMSVINN.DLL |
DBMSVIN3.DLL |
|
Shared Memory |
DBMSSHRN.DLL |
n/a |
|
DECnet |
DBMSDECN.DLL |
n/a |
Installing Client Connectivity
You install client connectivity with the same Setup program that you used to install SQL Server. You must choose a Custom install. The client workstation must have the Client Connectivity libraries installed. You can install the management tools (Enterprise Manager, Query Analyzer, and so on) and Books OnLine, but you do not need to. You might want to put these tools on developer workstations. Only C and C++ programmers need the development tools. Developers might also benefit from the code Samples. You specify what you want to install on the Components Selection screen shown in Figure 3.11.
){kind=link}
Figure 3.11 Client Components Selection screen.
When you install Client Connectivity on Windows NT or Windows 9x, by default the client is using named pipes. If that client wants to connect to a server running on Windows 9x, you must change the default network library to TCP/IP. Do this with the Client Network utility.
Warning
A common misunderstanding has to do with how multiprotocol works. Although it can work over the NT network protocols—NetBIOS, TCP/IP, and NWLink IPX/SPX—it doesn't necessarily mean that the client can send requests using any of those network libraries. If you are using multiprotocol on the server, you must also use it on the client.