Database Engines:odbc

About Client/Server Concepts Professional

In its broadest sense, a client/server system can be viewed as a model for application development where different tasks are performed by at least two computers. One computer, the client, sends requests to the second computer, the server, which replies to the request by returning data to the client, for example. A rudimentary form of a C/S system is a file server used as a central storage for files accessed by many client stations. This way, data can be shared between multiple computers in a network, and is available for multiple users at the same time.

Many of today's PC-based database applications use a file server for data sharing, especially those written in an Xbase language. Their common denominator is the DBF file format for database files which is widely accepted for its simplicity and ease of use. A DBF file is usually accompanied by one or more index files which are opened along with the DBF file and allow for rapid access of the data stored in it. When such data is requested from a client station in a network, it is the file server which opens the file for the client and returns the requested data. The client computer, in turn, presents the data to the user, who may change data. All changed data is sent back to the file server and written into a DBF file, so that changes become permanent and visible to all other client computers in the network.

All Xbase database applications relying only on a file server for opening, closing and updating database files are easy to maintain since there is verly little administrative work required for database maintenance. However, they all suffer from technical restrictions and disadvantages imposed partly by the Xbase language and partly by the file server concept. This can lead to a rapidly declining performance in a growing network, frequent index file corruptions or even a loss of sensitive data.

For example, a file handle is used whenever the file server opens a file for a client station. If 10 clients request data from the same database file at the same time, the server opens that file 10 times and uses 10 file handles. When the network grows to 100 client stations it becomes obvious that file handles can become a limiting factor on the server. The more so, when a medium sized database application runs which uses 10 DBF files, each accompanied with four index files. This requires 50 file handles on the server for one client station, and 5000 handles for 100 clients.

The really critical situation in file server based database applications, however, occurs each time a user changes data on a client station that requires the file server to update multiple files. This happens when data must be written to a single DBF file that is opened along with index files, or when multiple DBF files must be updated. If something goes wrong before the file server has updated all files -be it a server break down, a power outage or something else- the integrity of data is no longer guaranteed.

This situation is resolved using a Database Management System (DBMS), such as an SQL Database, as an additional "layer" between file server and client station. When a DBMS is installed on the file server, it takes the role of a mediator between the file server's operating system and a client station by receiving a client's request, routing it to the file server and returning the reply. This not only leads to a true client/server architecture but has some major advantages:

Files are opened on the file server by the DBMS only once for all client stations. This reduces the required number of file handles drastically.
The DBMS can monitor the success of file updates, or transactions, and secure the integrity of the database.
The client application can take advantage of functionalities built into the DBMS.

These advantages lead to a high level of data security and relieve the programmer from programming tasks that can be "outsourced" to the DBMS. Each task that can be performed by the DBMS results in less network traffic in a multi-user environment.

Feedback

If you see anything in the documentation that is not correct, does not match your experience with the particular feature or requires further clarification, please use this form to report a documentation issue.