Server Configuration Parameters
Each Pervasive PSQL database engine has its own server configuration options. This section describes the different configuration options available for the engines.
You can configure Pervasive PSQL Servers on Windows and Linux platforms using the graphical utility Pervasive PSQL Control Center. You can also use the command-line interface utility bcfg. For PCC, see Using Pervasive PSQL Control Center in Pervasive PSQL User's
Guide. For bcfg, see Configuration Through CLI Utility.
The following table lists the Server configuration options and their settings.
Table 9 Server Configuration Options and Settings
Configuration Option Setting Name
Access Accept Remote Request
Allow Cache Engine Connections Allow Client-stored Credentials Authentication (Linux engines only) Configuration File (Linux engines only) Prompt for Client Credentials
Wire Encryption Wire Encryption Level
Compatibility Create File Version System Data
Data Integrity Archival Logging Selected Files Initiation Time Limit
Operation Bundle Limit Transaction Durability Transaction Logging Wait Lock Timeout
Debugging Number of Bytes from Data Buffer Number of Bytes from Key Buffer Select Operations
Trace File Location Trace Operation
Directories DBNames Configuration Location Transaction Log Directory Working Directory Information Server name (display-only)
Engine version (display-only) Engine type (display-only)
Table 9 Server Configuration Options and Settings
Server Configuration Parameters
Access
Access contains the following configuration settings: Accept Remote Request
Allow Cache Engine Connections Allow Client-stored Credentials Authentication (Linux engines only) Configuration File (Linux engines only) Prompt for Client Credentials
Wire Encryption Wire Encryption Level
Performance Tuning Cache Allocation Size Communications Threads File Growth Factor Index Balancing
Limit Segment Size to 2 GB Log Buffer Size
Max MicroKernel Memory Usage Number of Input/Output Threads Transaction Log Size
Table 9 Server Configuration Options and Settings
Allow Cache Engine Connections
Specifies if the server will support clients that will attempt to connect to the server with the Cache Engine. When set to Off, clients will still connect to the Server but will not use the Cache Engine.
Allow Client-stored Credentials
When this setting is On, the database engine accepts user credentials stored on the client. The method and location of storage depends on the operating system of the client:
Windows clients: these credentials are stored in the Windows registry. When the Prompt for Client Credentials is set to On, then a pop-up dialog allows you to save the credentials by selecting the Save User name and Password check box.
Alternatively, you can use the pvnetpass command-line utility to manage stored credentials.
Linux clients: credentials are stored in the Pervasive registry by the pvnetpass utility.
When this setting is Off, the database engine forces the client to omit stored credentials from any database operation that requires
Type Range Default Units Requires Engine Restart
Boolean On Off
On None Yes
Type Range Default Units Requires Engine Restart
Boolean On Off
Server Configuration Parameters
other hand, in environments where unauthorized personnel are present or authorized users have varying levels of access permissions, this setting must be Off.
See also: Prompt for Client Credentials.
Summary Chart of Login Behavior
Table 10 Summary of Login Configuration Behavior
Prompt for Credentials Allow Client- Stored Credentials Behavior
Off Off Pervasive PSQL client does not prompt the user or use stored credentials, thus credentials must be supplied by the client application during a Btrieve operation.
Off On If credentials are not supplied by the client application during the Btrieve operation, the client uses credentials stored by the login dialog or by pvnetpass, if such credentials are available. If no credentials are supplied by either method, the connection attempt fails. No login dialog is displayed.
On Off If credentials are not supplied by the client application during the Btrieve operation, the client displays a login dialog to the user, and the Linux client returns a status code for permissions error. Credentials stored by the login dialog or by pvnetpass are not used.
Authentication (Linux engines only)
The following options specify which type of authentication to use for access to the server engine. The available options are:
Emulate Workgroup Engine. Use this value when Samba is used to authenticate user access on the system. If you want to bypass security provided by the operating system and do not want to store RTSS passwords in the registry, use Emulate Workgroup Engine.
Proprietary Authentication (using btpasswd). Use this value when not using Samba to authenticate and the user does not have an account on the server. This allows a separate password file to be maintained when connecting to the Linux system. If you are using BTPASSWD authentication on your Linux server, user names and passwords must be set from clients connecting to this server. Use Pervasive PSQL Control Center or the pvnetpass utility. See Groups, Users, and Security and
pvnetpass, both topics in the Pervasive PSQL User's Guide. Use Proprietary Authentication if stronger security is needed for the server and you want user names and passwords different from any user authentication scheme employed on the Linux server.
Standard Linux Authentication. Use this value when not using
Type Range Default Units Requires Engine Restart SelectOne Three options. See below Emulate Workgroup Engine None Yes
Server Configuration Parameters
If the Pervasive PSQL installation detects PAM, the installation completes its configuration so that PAM can be used. If you install PAM after installing Pervasive PSQL and want to use standard authentication with PAM, you must re-install Pervasive PSQL. The reason is that the PAM installation copies files, creates configuration files, sets permissions, and creates links. Pervasive PSQL needs to be re-installed to detect PAM and correctly complete its PAM configuration.
You re-install Pervasive PSQL by uninstalling and then installing again. See the chapter Installing Pervasive PSQL Server and Client for Linux in Getting Started With Pervasive PSQL for the steps to uninstall and install.
Samba and Authentication
You may use Samba, if available, in addition to any of the three authentication methods described above. The server creates a well- known FIFO share via Samba. FIFO is created in $PVSW_ROOT/etc/ pipe/mkde.pip. $PVSW_ROOT/etc/pipe should be shared by Samba as PVPIPE$.
Note The trailing $ means this share will be hidden. The Pervasive PSQL client components automatically take care of accessing this pipe as \\<server>\PVPIPE$\mkde.pip (case- insensitive); you do not need to perform any explicit actions or modify your application to access this pipe. The only exception to this is if you are troubleshooting your Samba or Pervasive PSQL configurations (see section on Troubleshooting below).
The installation program sets up the Samba share (if Samba is installed on the server). For reference, here is an example of setting up the Pervasive pipe.
################################################### [PVPIPE$]
comment = Pervasive pipes path = /usr/local/psql/etc/pipe force group = pvsw
# force group pvsw when accessing pipe - will be # useful if primary group for this user is not pvsw valid users = @pvsw
# only members of group pvsw will have access oplocks = False
# Absolutely necessary - prevents caching on the client
################################################### To configure access to files shared through Samba, read the Samba documentation.
Note By allowing a client read access to PVPIPE$, that client is authorized to access the engine remotely.
A simple way to ensure the client gets proper authentication is to enter \\<yourserver>\pvpipe$\mkde.pip at the command prompt. You should see a lot of question marks (unprintable symbols), occasional printable characters and hear beeps. If you do not, check your Samba configuration to be sure you have rights to read this pipe. If you do but still get error 94 or 3119, validate your
Server Configuration Parameters
Configuration File (Linux engines only)
This setting specifies the location of the smb.conf file used by Linux to export local file systems to Windows clients. The engine requires this file to translate UNC paths on remote systems into local calls to the correct database file.
The default value is /etc/smb.conf. If you installed the Samba configuration file in a different location, enter the correct path and/ or file name.
Prompt for Client Credentials
This setting determines whether the Windows Pervasive PSQL client prompts the user for login credentials if no other credentials are available during a database operation that requires user
authentication.
When this setting is On, in the absence of other authentication credentials, the engine requires the Windows client to present a login dialog to the user. This setting only applies when Mixed or Database
Type Range Default Units Requires Engine Restart
String not applicable /etc/smb.conf None Yes
Type Range Default Units Requires Engine Restart
Boolean On Off
See Also
Allow Client-stored Credentials
Wire Encryption
This parameter specifies whether the given client or server should use encryption for its network communications. The default value of If Needed means that the client or server only uses encryption if the other end of the communication stream requires it. For example, assume that Server A has its Wire Encryption value set to Always. Server B has its value set to Never. Your client has its value set to If Needed. In this case, the client will use encryption when
communicating with Server A, but it will not use encryption when communicating with Server B.
The following chart summarizes the behavior given each possible combination of client and server values:
Type Range Default Units Requires Engine Restart
Single select
Never If Needed Always
If Needed None Yes
Table 11 Client/Server Results of Wire Encryption Combinations
Client Setting
Server Setting “Never”
Server Setting “Always” Server Setting “If Needed”
Never Encryption not used
Status Code 5001 Encryption not used
Always Status Code 5000
Encryption used; level determined by highest Wire
Encryption used; level determined by
Server Configuration Parameters
Wire Encryption Level
This setting specifies the strength of the encryption key that should be used for encrypted communications. The following levels are available:
Encryption using a key 128 bits long is generally accepted as “strong” encryption. The other settings provide progressively less protection but higher performance, in the event that you require some level of encryption but are willing to accept a lower level of deterrence to gain better performance.
When a client and a server both require encryption and one specifies a stronger encryption level than the other, the two entities use the stronger level to communicate. When a client and a server both require encryption and one specifies a stronger encryption level than
Type Range Default Units Requires Engine Restart
Single select
Low Medium High
Medium None Yes
Table 12 Meaning of Encryption Level Values
Value Meaning
Low 40-bit encryption key used Medium 56-bit encryption key used High 128-bit encryption key used
Auto Reconnect Timeout
This setting specifies how long the client will attempt to connect to the server before giving up. When a AutoReconnect-enabled client first connects to a AutoReconnect-enabled server, the server communicates this value to the client so that both components know how long to attempt to reconnect in the event of a network
interruption.
Enable Auto Reconnect (Windows only)
This setting specifies whether you want the server to support clients attempting to auto-reconnect during a network outage. A setting of On means AutoReconnect is enabled.
Auto Reconnect is not in effect for a given client connection unless this setting is also enabled in that client’s configuration.
To specify how long a client will attempt to reconnect to the server before giving up, see Auto Reconnect Timeout, above.
Listen IP Address
Type Range Default Units Requires Engine Restart
Numeric 45 - 65535 180 seconds Yes
Type Range Default Units Requires Engine Restart
Boolean On Off
Off None Yes
Server Configuration Parameters
Multiple IP addresses may be specified but must be separated by a comma between each address. The string can be a combination of IPv4 and IPv6 addresses. Any of the IPv6 address formats supported by Pervasive PSQL can be used. See Drive-based Formats in Getting
Started With Pervasive PSQL.
NetBIOS Port (Workgroup engines only)
This option specifies the NetBIOS port the MicroKernel listens on. The Server engine does not support NetBIOS.
Supported Protocols
This setting specifies the protocols on which the database engine listens for client connections. If more than one protocol is specified, the database engine listens on all specified protocols. The default is TCP/IP. The available options are:
TCP/IP SPXII NetBIOS
Type Range Default Units Requires Engine Restart
Numeric 33 to 254 66 None Yes
Type Range Default Units Requires Engine Restart
TCP/IP Multihomed
This option specifies whether the database engine should listen for client connections on all network interfaces. If it is set to On, the database engine listens on all network interfaces, and the IP address(es) listed in the Listen IP Address option is ignored. If this setting is Off, you must specify in Listen IP Address which
address(es) for the database engine to use for client communications.
TCP/IP Port
This setting configures the port number used by the relational interface.
This port number must be the same as that defined in any Client DSNs pointing to this server. For information on how to change the port number in a Client DSN, see Advanced Connection Attributes for Client DSN in SQL Engine Reference.
For additional information on ports, see Changing the Default Communication Ports in Getting Started With Pervasive PSQL.
Compatibility
Compatibility contains the following configuration settings:Type Range Default Units Requires Engine Restart
Boolean On Off
On None Yes
Type Range Default Units Requires Engine Restart
Server Configuration Parameters
Create File Version
This setting specifies the format in which all new files are created. The 10.x database engine can write to files using the existing file format. In other words, it writes to 7.x files using the 7.x file format, writes to 8.x files using the 8.x file format, and so forth. (The 10.x database engine can read files created with 5.x, 6.x, 7.x, 8.x, and 9.x versions of the database engine.)
Specify 6.x, 7.x, or 8.x only if you need backward compatibility with a previous version of the MicroKernel. Specifying a previous file versiondoes not affect any existing 9.x files.
Note Dictionary files (DDFs) must be created with a file format of 6.x or later. The New Database wizard uses the setting for create file version. The data files can be in any of the previous file formats supported. Only the DDFs must use a file format of 6.x or later.
System Data
Type Range Default Units Requires Engine Restart
SelectOne 6.x - 9.x 9.x None No
Type Range Default Units Requires Engine Restart
Always. System data is always added on file creation, regardless of whether the file has a unique key.
Note The System Data setting does not affect existing files. This setting only affects how new files are created.
If you want to use transaction durability with a file that was not created with System Data turned on and does not have a unique key, you must re-create the file after setting System Data to Yes or If needed.
The SRDE always creates files with System Data. This information applies to files created through SQL, OLE-DB, JDBC, or any method other than the Btrieve API.
Even if a file has a unique key, you may want to include system data, because users can drop indexes.
Data Integrity
Data Integrity contains the following configuration settings: Archival Logging Selected Files Initiation Time Limit
Operation Bundle Limit Transaction Durability Transaction Logging Wait Lock Timeout
Archival Logging Selected Files
Server Configuration Parameters
logging by adding entries to an archival log configuration file that you create on the volume that contains the files. For more
information about archival logging, refer to Understanding Archival Logging and Continuous Operations.
Initiation Time Limit
This setting specifies the time limit that triggers a system transaction. The MicroKernel initiates a system transaction when it reaches the Operation Bundle Limit or the time limit, whichever comes first, or when it needs to reuse cache.
Operation Bundle Limit
This option specifies the maximum number of operations
(performed on any one file) required to trigger a system transaction. The MicroKernel initiates a system transaction when it reaches the bundle limit or the Initiation Time Limit, whichever comes first, or when it needs to reuse cache.
The MicroKernel Database Engine treats each user transaction
Type Range Default Units Requires Engine Restart
Numeric 1 - 1800000 10000 milliseconds No
Type Range Default Units Requires Engine Restart
Transaction Durability
Transaction Durability is the same as Transaction Logging except that Transaction Durability guarantees that all successfully
completed transactions are committed to the data files in the event of a system crash.
For a full discussion of transaction logging and durability, see
Transaction Logging and Durability.
Note When you turn Transaction Durability on, some files may not be able to support the feature. A file must contain at least one unique key, or when it was created, the configuration setting System Data must have been set to “Yes” or “If Needed.” Otherwise, any changes to the file are not written to the transaction log. For more information about transaction durability and system data, refer to Pervasive PSQL
Programmer's Guide in the Developer Reference.
Because System Data does not affect existing files, you may need to re-create files that do not have a unique key and were not created with System Data turned on. Be sure to turn on System Data before re-creating these files.
Caution Gateway locator files allow different engines to manage
Type Range Default Units Requires Engine Restart
Boolean On Off
Server Configuration Parameters
Related Settings
See more information on similar and related settings under
Transaction Logging. Transaction Logging
This setting controls whether the MicroKernel ensures atomicity of transactions by logging all operations that affect the data files. If the related setting, Transaction Durability, is turned on, then logging takes place automatically, and the Transaction Logging setting is ignored.
For a full discussion of transaction logging and durability, see
Transaction Logging and Durability.
Note When you turn Transaction Logging on, some files may not be able to support the feature. A file must contain at least one