| # LN user in a client-server environment The client/server architecture as supported by LN enables the LN user to work with several database types. One or more systems can distribute these databases. A remote database configuration is one on which an application server (Virtual Machine) and the database are not on the same system. If the LN database driver is run on the remote database server, LN users can only access the RDBMS by a remote user account. In a client/server environment, the Master Application Server (MAS), which stores the run-time data dictionary, can be located on the remote system. In that case, the LN user must have a remote user account to retrieve software components from the MAS. Possible reasons to set up a remote database configuration include the following: System performance: If all users start the application on the same system, the CPU is primarily occupied by the Virtual Machines. You can divide the load by enabling the users to work on local systems and keeping the database on a remote system. Lack of disk space on local system: If all tables cannot be stored on the same system due to a lack of disk space, some of the tables can be installed on a second system. Distributed applications: For practical reasons, you can decide to install the application tables on different systems per application. Mirrored databases: For security reasons, database actions can be carried out on two systems simultaneously by database mirroring. The database tables can be located in various ways in a remote database configuration. For example, a part of the tables can be located on the local system and another part of the table can be is located on a remote system. The following figure shows an example of a remote database configuration: Example of a remote database configuration In this figure, the application logic (Virtual Machine) is installed on the local host, while the database resides on a remote system. To be able to work with distributed or remote databases, the LN users that are logged in to the local system must be able to connect to the database on the remote system. The two possible scenarios are the following: The database driver runs on the (local) application server and communicates with the remote database through the database’s own connection utility, for example, iConnect (Informix) or SQL NET (Oracle). In this case you do not have to create remote user files, which is the most common scenario. The database driver runs on the remote database server. In this case, you must create remote user accounts for the LN users through which the users can connect to the remote database. The remote user files are stored on the local application server. This scenario is rarely used and not recommended. |