UNDERSTANDING CLIENT/SERVER

Because of the confusion over what client/server is and its importance in the marketplace, a definition of client/server needs to be provided. You also need to understand what Open Database Connectivity (ODBC) is and why Access is a good selection as a front end for client/server applications. Last—and most important—you need to be aware of the factors for client/server migration.

Explaining the Term Client/Server

Everyone's talking about client/server, and although more people understand it and know how to implement a client/server solution, some people falsely believe that merely having data on the server and the application on the desktop means they're running a client/server application. In fact, many people confuse their file-server applications for client/server.

By definition, client/server means having all application data stored in a back-end server that specializes in query processing and data management, such as SQL Server or Oracle, that's accessed from a front-end client application. In client/server applications, you're actually running two separate programs: one on the client machine and one on the server. The client application manages the interface while the server application manages the data. Client/server requires that both programs communicate with each other for the application to work.

In direct contrast, a file-server application has one program managing the entire application, although the application code and the data might reside in different locations and files. For example, an Access application that retrieves data stored in an Access .mdb file on your LAN isn't a client/server application—it's a file-server application. In this scenario, the .mdb file on the LAN is merely a holding container for data; no query processing takes place in the data .mdb file. SQL Server and its data are located on a Windows NT server. You send the request to the server; the server processes the request and sends back only the results that the application needs.

Working with Open Database Connectivity

Now that you know what client/server is all about, how does it work? Client and server applications need to have a common language or a translator to communicate with one another. Open Database Connectivity (ODBC) is an open standard that allows communication between applications and various database servers. This has been leading the way for client/server development.

The ODBC drivers available provide a translation layer between front-end applications and their server data storage. For example, the ODBC driver for SQL Server allows Access to communicate seamlessly with Microsoft SQL Server. Drivers are also available that allow an Access application to communicate with non-Microsoft database servers (such as Oracle and Sybase) and with file-server databases (such as FoxPro and dBASE).

Figure 24.1 depicts ODBC's architecture.

The components involved in ODBC are as follows:

• Application. This is your front-end application on the client machine. The data request is sent from the application to the ODBC Driver Manager. For example, in client/server development, this would be a front-end application developed in Access.

• ODBC Driver Manager. Here, the application's request is translated for the database-specific driver.

• ODBC Driver. The ODBC driver sends the request across the network to the back-end database server. For example, if the back-end server is SQL Server 7.0, this would be the SQL Server–specific ODBC driver.

• Network. The back-end server resides here. The initial request from the application crosses the network to reach the server.

• Database Server. This is where your data request is fulfilled. For instance, SQL Server would process the query that originated from Access and send the data back across the network server to the front-end application.

Understanding the Reasons to Use Access for Client/Server

Access lends itself well to being a suitable front end for client/server applications:

• Access provides an easy-to-use tool for scalable development work. With proper foresight, you can easily migrate to client/server applications that use Access for both the client application and data storage.

• Compatibility is another large selling point for Access. There are ODBC drivers for the most popular database servers and file formats.

• Another issue is cost per user. If you use the Office Developer Edition tools (ODE) to create a runtime version of your application, there's no royalty or per-seat charge for end users to use Access. Specifically, the installation disks that the ODE creates include a runtime version of Microsoft Access that's used to run your application. Using the ODE allows an unlimited number of end users to run your application without requiring them to buy a license for Access. Keep in mind, however, that many back-end servers do have a per-seat or connect-time charge.

Additionally, by using the new Project (.adp) file type, Access provides native-mode connectivity to SQL Server databases. You can now design and develop SQL Server databases with the Access user interface and connect Access forms and reports to server data. See Chapter 25, “Developing SQL Server Projects Using ADPs,” for more information on Access Projects.