The following topics explain engine configuration settings for some common environment scenarios:

Microsoft Terminal Services is a multi session environment that provides remote computers access to Windows-based programs running on a server.

In prior releases, the ability to perform administrative functions was prohibited from the client. In the current release, PSQL clients running within Terminal Services client sessions can perform PSQL administrative functions by default. For example, a user with such a client can change configuration settings for PSQL, create DSNs, and use the Monitor utility.

If you want to restrict this capability, intervention is necessary from a system administrator.

You may use your terminal server as your main network server and database server. However, if you have high usage of the server as a file server as well as many terminal sessions running at the same time, you may find the performance less than satisfactory.

Another concern is having all of your mission critical services on the same machine. If it goes down, all of your services go down at once.

For these reasons, you may wish to consider distributing your mission critical services on two or more computers.

By default, Workgroup Engine is installed to run as a service for a fresh install. This allows the engine to start automatically when the operating system starts. A user is not required to log in to start the engine.

During a Custom installation you can select to run the Workgroup Engine as a console application. Or, if you upgraded your Workgroup installation and you had the previous version installed to run as an application, the upgrade installation is also set to run as an application. In either case, if you decide that you would rather run the Workgroup Engine as a service, you change how it is run. See Running the Workgroup Engine as a Service.

Active Directory is a central component of the network architecture on certain Windows operating systems. Active Directory provides a directory service specifically designed for distributed networking environments.

This section describes the conceptual steps to configure PSQL in an environment that has Microsoft Active Directory service installed and functioning correctly.

Ensure that Active Directory service is installed and functioning correctly before you install PSQL into the environment.

PSQL Server runs on supported Windows Servers within an Active Directory environment. The PSQL client runs on all supported Windows platforms within an Active Directory environment.

The database engines enforce directory and file permissions set at the operating system level. An Active Directory environment does not change this behavior. For example, if you set “read only” permission on a PSQL table file, you will be unable to write to the table.

PSQL Server engines are supported for use with Microsoft Terminal Server running within an Active Directory environment. For more information about Terminal Services, see Terminal Services.

Active Directory service manages the security of the network. You must grant the correct access authority at the operating system level to users who need PSQL administrative privileges.

See Active Directory Tasks for the general steps to set access authority. Users must have the following authority on the machine running the database engine:

You can grant the Log on locally authority directly to a user or to the Pervasive_Admin group (and add the user to the group).

You can create the Pervasive_Admin group on the machine running the database engine (the local machine), on the domain controller for the local machine, or on both. The database engine checks privileges first on the domain controller for the local machine then on the local machine.

An example helps illustrate this. Suppose you have two servers in your domain that run the PSQL database engine, Server A and Server B. You could create a Pervasive_Admin group on each server and on the domain controller. You then add User 1 to the group on Server A, User 2 to the group on Server B, and User 3 to the group on the domain controller. User 1 has administrative privileges for the database engine only on Server A. Similarly, User 2 has administrative privileges only on Server B. User 3, however, has administrative privileges for the database engines on both Server A and Server B.

If you create the Pervasive_Admin group on a domain controller, then the group must be a domain local group. If you create the Pervasive_Admin group on a machine that is not a domain controller, then the Pervasive_Admin group must be a local group.

Use the following steps to create a Pervasive_Admin group in Active Directory to grant users PSQL administrative privileges in a Windows environment. The steps assume that you are setting privileges on the domain controller for the machine running the database engine.

These steps continue from step 5 in the previous task when you cannot use the Log on locally option in a group policy.

Sometimes, two or more client-server applications may use the same database engine. You will need to configure the database engine differently depending on whether the applications are used at the same time.

If your vendors supply configuration guidelines for engine configuration parameters, you will need to adjust your configuration based on these guidelines.

Most engine settings are not affected when you are running multiple applications. This section explains the settings that may need to be adjusted for multiple applications.

Some applications may require that new files be created with version 7.x file format, while other applications may require the default version 9.5.

These applications can run concurrently only if new files are not created during run time. There is no way to toggle the setting back and forth for each application, unless you wish to do it by hand or write a program to do so using Distributed Tuning Objects.

If the applications do not create new files during run time, then this setting is not relevant for multiple applications.

Some applications may require durable transactions, while others may not. If you have two application vendors recommending different values for this parameter, then you should set it to On. Generally, having transaction durability turned on does not affect applications that do not use transactions, but may slow performance.

The Server engine allows both remote client requests as well as communications from applications running on the same computer as the server.

The Workgroup engine can be configured to access files on a remote file server through a mapped drive on a Windows server.

The client software installed with your Workgroup engine can be used to connect to other server engines on a remote machine.

If you want to use your local engine for local file access and a remote server for access to files being serviced by the remote PSQL server, you must change the settings in your MicroKernel Router. Use the PSQL Control Center to change MicroKernel Router settings.

The Workgroup engine provides great flexibility for a variety of small networked environments. The table below explains the most common configurations and where to look for more information. In any of the configurations below, a Workgroup engine must be installed on every computer that is expected to access data.