Client Server Database Online

  

 

Get Smart With Your Client/Server Apps

Everybody knows how to build micro-based database applications, right? Just install the database program on the PC, spend a few minutes designing the database and then start writing the application.

Not in the client/server world. 
 

With applications that involve both client and server software, quite a bit of behind-the-scenes work is required before developers can write a line of code. Unless they recognize the need for this work and schedule time for it, companies will find client/server projects inexplicably slow at first.

The client/server world involves three distinct entities: the server machine, the client machines and the network that connects the two. The server and clients must be able to communicate over the network before they can run any useful software.

Basic network connectivity

The first step is to establish physical connectivity between the clients and the server. Like the entire prep process, this is best done on a few pilot client systems. Once those systems are up and working, administrators can copy the working setups to actual client machines while minimizing the disruption for people using those machines.

To make sure the clients and the server are on the same network segment, install the appropriate network adapter in each client machine and connect that machine to the network with the appropriate type of cable. This task is best left to the network administrator. In some organizations, the clients and server machine will already be running on the appropriate network.

The next step is to establish connectivity between the basic network-protocol stacks running on the client and server machines. On the client side, this usually involves loading the network-adapter drivers for the appropriate network protocols. (Those would be SPX/IPX for a NetWare network, TCP/IP for a Unix network and so on.) Having some network protocols running on the clients may not be enough, because the database server may require a different network-protocol stack. Some database servers, for exampl e, are available on Unix systems but not as NetWare Loadable Modules; such servers often require TCP/IP protocol stacks on the clients.
Consider, for example, an organization that wants to plug a Unix-based database server into an existing NetWare network. The client PCs are running SPX/IPX, but the database server needs TCP/IP. Simply changing the clients to use only TCP/IP is probably not an option, because the clients need SPX/IPX for their existing file and print services.

The answer is to install on the client PCs a mechanism that lets the SPX/IPX and TCP/IP stacks coexist. One of the best ways to do this is to install drivers that obey an interface standard designed to work with multiple protocol stacks. Two such standards are Microsoft Corp.’s Network Driver Interface Specification (NDIS) and Novell Inc.’s Open Data-Link Interface (ODI).

Both NDIS and ODI drivers work the same basic way. Each loads a low-level driver for the adapter, then loads a piece of protocol-independent software. With this software, the client PC can run multiple protocol stacks, each of which talks to the same single protocol-independent layer.

The main drawback of this approach is RAM consumption. Administrators must load as much of this software as possible into high memory, or client PCs running DOS or Windows may run up against the conventional 640K-byte limit.

This approach can also be quite expensive, frequently in ways that are not initially visible. Switching to ODI drivers, for example, will work only if all the network adapters in the client PCs have network adapters for which ODI drivers are available.

Basic server connectivity

With the proper network protocols installed and the client systems able to connect to the server, the next step is to link the front-end program and the server-database software.

Most database-server packages include their own network drivers for this purpose. Those drivers, which are installed on the client machines, format network data in such a way that both the database server and its compatible client front ends can handle it.

Oracle Corp.’s Oracle database server, for example, comes with a driver called SQL*Net, which provides a layer of abstraction between all Oracle client front ends and the underlying network protocols. With NetWare networks, for example, SQL*Net uses Oracle’s SPX to link clients to an Oracle server.

These drivers often use one or more configuration files to control their operation, and each of those configuration files must be set up correctly. The drivers can easily consume 50K bytes or more of RAM, so they can aggravate the RAM-cram problem.

The result of this effort should be the client front ends successfully talking to the database server.

At this point on PC clients, however, RAM can be so tight that the front ends don’t have enough RAM to run. If that happens, it’s time to pause and go through all the usual steps to regain RAM: Consider using a memory manager, load high as much software as possible and so on.

Putting all the pieces together

When the RAM problem is under control, the next step is to set up user accounts and permissions in the database server.

First, log in to the database server. Some of the preceding steps may require the special privileges of an administrator account, but don’t be tempted to keep using that account while setting up the front-end packages. Use an account with standard user privileges to test the links between the front ends and the database server. Unless the eventual users of the client/server application will have special privileges, developers should not use privileged accounts.

Some databases even come with a built-in user account for this kind of testing. Oracle, for example, includes a user ID SCOTT with a password of TIGER for running tutorials and verifying that everything works.

After the log-on process, all that remains is to verify that a standard user account can indeed read and write to the database. The easiest way to conduct this verification is to use one of the sample database tables that most database-server vendors include with their products. When the front ends can manipulate one or more of these sample tables, all the pieces are in place.

A STEP-BY-STEP GUIDE TO HELP PUT YOUR CLIENT/SERVER DATABASE ON-LINE

1. In many organizations, the client systems already will be connected to the same network as the database server system. If they are not, install the appropriate LAN adapter and cables on the client machine.

2. Install the network protocol stack (for example, SPX/IPX, TCP/IP or NetBEUI) on the client that is needed to communicate with the database server. Again, in some organizations those protocols already may be running on the clients.

3. Ensure network coexistence. This is necessary when the clients are running a network protocol, but not the one needed to talk to the database server. A network protocol coexistence standard –such as NDIS or ODI — will enable the client’s network adapter simultaneously to run both its current protocol stack and the protocol stack required by the database server.

4. Install the software that communicates between the database front-end applications and the database server’s protocol stack. For Oracle servers on a NetWare network, for example, the SQL*Net drivers for SPX/IPX are necessary.

5. Check for sufficient RAM. On PC clients, adding all these pieces of software — network protocol, network coexistence and database connectivity programs — can cause RAM shortages. To have enough RAM to run the database front-end application, the installer may need to regain RAM by taking such steps as loading software high and using a memory manager.

6. Establish a database user account. Use a standard user account, not a privileged administrator account, for all testing. Either use an available default user account that the database server includes or create a user account for development and testing.

7. Log in to the database with the selected user account. Verify that the account and the other developer accounts can work with sample database tables

8. Get to the “real” work. Start designing the database, laying out the prototype screens and building the client/server application.

Share this post