In a configuration of this type the applications have access to a local copy of the database, in addition to the database on the server. The database manager initially handles messages sent by the application program, and decides whether to process them itself or to pass them on to the network client.
In a typical configuration of this type static or infrequently changing information is held on the local database, but transation data is normally written to the remote database. In the event of a network problem the application seamlessly switches to storing transaction data locally. The system would incorporate programs to transfer such locally held transaction data up to the remote server, and to download updates to the infrquently changing data (for example price updates).
Each client accesses certain tables on its local database and certain other tables on the database on one of the server machines. By default, all the base dictionary tables are local, and all the application tables are remote; this default can be changed using makedb -expert. Updates can be made to both sets of tables. The system database is always accessed entirely locally.
Obviously, at least one machine somewhere must be configured to act as a server. You can use any of the possible server configurations described elsewhere as a server for local database resilience clients. Refer to How To Choose an Appropriate Networking Configuration for a comparison of the various possibilities. The simplest server configuration, the Server Only configuration is described here.
Instructions for loading a machine as a local database resilience client can be found here.
In a local resilience configuration, different client machines can access different servers, but each client can access only one remote server. (However, you can use the Named Connection Facilities to make an application use a different server in this configuration, provided you set the default server by using the -server_name servername command tail on the network requester, and not by specifying -server n on the database manager.)
With the exception noted in Resilience Command Tails for the command tail -NOFAIL, parent and orphan checking and child deletion are carried out on the local database for records posted to the local database, and on the remote database for records posted to the remote database. No cross-database checking or child deletion is ever done.
It is not possible for other machines to access the local database on client machines. You must not attempt to run the network manager on machines running with the Local Resilience Client software. If access to the local database is required from other machines you must use either a Multiple Resilience Combined Client/Server or a Named Connection configuration.
There is no automatic provision for moving data from the local database to the remote when connection is reestablished. An application program must be written to do this.
From the point of view of the programmer, the local database resilience configuration is less controllable than a Multiple Resilience or Named Connection configuration. For example, a program cannot easily find out whether a table should be stored locally or remotely, nor change the error handling mode from the default.