License Administration Concepts
This section discusses the following topics:
•
License Models
•
License Enforcement
•
Message Logging
License Models
The Pervasive PSQL products use different license models depending on the product. Pervasive PSQL Server and Workgroup use a user count license model. Pervasive PSQL Vx Server uses a capacity-based license model.
User Count License Model
The user count license model works well for traditional client/server applications in which many users or devices constantly add, update, and delete records from distinct individual desktops. Each product key specifies a licensed user count. A user count allows the specified number of concurrent connections to the Pervasive PSQL database engine. Users are counted by network address. The IP address is used for TCP/IP; the IPX address is used for SPX/IPX.
Each computer that accesses Pervasive PSQL as a client session counts as one user. Multiple applications on a single client computer are counted as one user, not separate users. Internally, Pervasive PSQL assigns each machine a serial number and all connections with the same serial number are recognized as coming from the same machine. A machine with multiple NICs, for example, is recognized as the same machine. Each Terminal Server session also counts as one user.
Collectively, all applications that access the database engine, use the same network protocol and address, and run on the same machine as the database engine count as one user.
Pervasive PSQL Server or Workgroup uses one user count for each unique incoming protocol from the same client computer session. If one application uses TCP/IP and another application uses SPX/IPX, two users are counted if both applications run on the same machine. If different address formats of the same protocol are used, only one user is counted. For example, if one application uses IPv4 and another uses IPv6, only one user is counted if both applications run on the same machine. IPv4 and IPv6 are just different address formats of TCP/IP.
Obtaining a User Count
An initial user count is provided as part of the product key. A product key is issued by Pervasive Software or by your application vendor if the Pervasive PSQL database engine is embedded in an application.
You may also increase the user count beyond the initial amount provided by the product key. See Increasing User Count.
Capacity-based License Model
Pervasive PSQL Vx Server is designed to support highly virtualized environments. For instance, Vx Server includes support for Cloud computing (private, community, and hybrid), as well as for full virtualization, partial virtualization, and paravirtualization. Pervasive PSQL Vx Server has no restrictions on hosting, connection pooling, Internet or intranet use. No additional license is required for use with hypervisor features such as live migration, failover, fault tolerance (FT), high availability (HA), and disaster recovery.
The technological and operational differences that come with virtualized environments require a license model optimized for such environments. The user count license model used for Pervasive PSQL Server and Workgroup does not suffice. That model works well for traditional client/server applications in which many users or devices constantly add, update, and delete records from distinct individual desktops.
Instead, Pervasive PSQL Vx Server uses a license model that shifts the emphasis from how many users to how much work the database server processes. The model is based on capacity to accommodate license enforcement in virtualized environments. For example, each instance of Pervasive PSQL Vx Server has capacity limits on both the number of sessions in use and the data in use. (Also, each instance is identified by a virtual hostname and all virtual MAC addresses.)
*Note: The information in this section about the capacity-based license model is abbreviated to give you a general understanding of the model. For complete details about the model, See License Model in Pervasive PSQL Vx Product Guide.
Definitions
A “session” is defined as a client ID used by the transactional engine interface or a connection to the relational engine interface. “Client ID” is defined as a 16-byte structure that combines elements provided by the application, by the client platform, and by the database engine to uniquely identify a database transaction context.
The number of sessions in use is a count of the concurrent sessions. For brevity, “number of sessions in use” is also referred to “session count.” “Session count limit” is the maximum permitted number of concurrent sessions as granted by a license agreement.
“Data in use” is defined as the total size of all concurrently open data files. (A data file is a file created by an application to provide the data processed by that application.) “Data in use limit” is the maximum permitted total size of all concurrently open data files as granted by a license agreement.
Obtaining an Initial Session Count Limit and Data In Use Limit
An initial session count limit and data in use limit is provided as part of the product key. A product key is issued by Pervasive Software or by your application vendor if the Pervasive PSQL database engine is embedded in an application.
You may also increase session count or data in use beyond the initial amount provided by the product key. See Increasing Session Count Limit and Data In Use Limit.
Licensing and Use of Terminal Server
A Terminal Server session is the equivalent of a stand-alone machine. The same criteria used for user count, session count, and data in use for a stand-alone machine also applies to a Terminal Server session.
License Enforcement
Licensing for Pervasive PSQL is enforced by the use of keys. License Administrator is the utility you use to manage those keys. The utility allows you to authorize and deauthorize keys and to view license information. The utility includes a graphical user interface (GUI) and a command line interface (CLI).
You authorize a key for one of two purposes:
•
Authorize a Product
•
Increase User Count, Session Count, or Data In Use
Authorize a Product
Product authorization is a key validation process that associates certain machine hardware and machine configurations to the license for a product (called the “product key”). This association results in a unique installation identification (ID) that ensures the copy of software is legitimate and on the appropriate hardware and software platform.
When you authorize a product key, the unique installation ID is sent to Pervasive to verify the authenticity of the key and to ensure that the key is not being used for multiple installations. This process authorizes the product for legitimate use. When the product key is authorized or deauthorized, your remaining authorizations display.
Note that after you have authorized a product on a machine, changes to certain hardware configuration items could disable the key. (Configuration changes on a physical machine such as hard drive serial number, network interface card, MAC address, BIOS firmware, CPU type, operating system running on the hardware, and machine name, and hostname or MAC addresses on a VM.) If you need to change hardware configuration, deauthorize the key first. Doing so disassociates the product key from its unique installation ID. After you complete the hardware configuration changes, you can again authorize the product key.
See also Key Platforms for additional details.
Authorization Access Through A Proxy Server
If you are using a proxy server, you need to configure it to allow license authorization. Configure the proxy server before you install Pervasive PSQL, or omit product authorization during installation and authorize the product after configuring the proxy server.
Windows
Pervasive Software recommends that you configure proxy servers through Windows Internet Explorer for the best results. Pervasive PSQL license authorization works seamlessly with no modifications needed when proxy servers are configured through Window Internet Explorer.
If you are currently using a proxy server that was not configured using Windows Internet Explorer, we recommend that you reconfigure it through Windows Internet Explorer. However, if using Windows Internet Explorer to configure your proxy server is not an option, use the following steps.
If you are using a 64-bit Windows operating system, there are two possible places where the Registry settings for proxy servers can be stored:
•
HKEY_LOCAL_MACHINE\Software\Pervasive Software\ELS\ key
•
HKEY_LOCAL_MACHINE\Software\Wow6432Node\Pervasive Software\ELS\ key
Depending on the PSQL edition (Server, Client, Vx Server, or Workgroup), the ELS proxy server settings can be created in either location. Licensing manager looks for its proxy server settings first in HKEY_LOCAL_MACHINE\Software\Wow6432Node\Pervasive Software\ELS\ key. If it cannot locate them there, it looks in HKEY_LOCAL_MACHINE\Software\Pervasive Software\ELS\ key.
Therefore, if you are editing Registry settings for proxy servers, you first need to find the correct location.
1
Begin by looking for a Wow6432Node. If it exists, edit the proxy server Registry settings in the Pervasive Software\ELS\key.
2
If it doesn’t, move to the Software directory and edit the proxy server Registry settings in the Pervasive Software\ELS\key.
After locating the correct key, use the following procedure.
1
Modify the Windows Registry and add the following to the Pervasive Software\ELS\ key at the correct node:
String Value
proxy_host
DWORD Value
proxy_port
String Value
proxy_userid
String Value
proxy_passwd
Note: The proxy_host and proxy_port values are the only ones required by Pervasive PSQL. Depending on the configuration of your proxy server, you may also need to add proxy_userid and proxy_passwd.
 
*Caution: Editing the Registry is an advanced procedure. If done improperly, the editing can cause your operating system not to boot. If necessary, obtain the services of a qualified technician to perform the editing. Pervasive Software does not accept responsibility for a damaged Registry.
2
Authorize Pervasive PSQL using License Administrator. See To Authorize a Key for the GUI and To Authorize a Key for the CLI.
Linux
1
Manually edit the ELS.INI file to include the following:
proxy_host
proxy_port
proxy_userid
proxy_passwd
Note: The proxy_host and proxy_port values are the only ones required by Pervasive PSQL. Depending on the configuration of your proxy server, you may also need to add proxy_userid and proxy_passwd.
 
2
Authorize Pervasive PSQL Vx Server using the command line interface License Administrator utility. See To Authorize a Key.
Considerations For No Internet Access
If the machine on which you are installing Pervasive PSQL does not have Internet access or is not connected to a machine with Internet access, you may authorize the product key using offline authorization.
Offline authorization consists of three phases. In the first phase, an Authorization Request Data file (*.ath) is generated on the machine without internet connectivity. During the second phase, the file is then uploaded to an authorization server from a machine with internet access. Upon completion of this transmission, an Authorization Key Data file is downloaded in the form of a product key (*.pky) file. In the final phase, the product key file is authorized on the machine without Internet connectivity and Pervasive PSQL is authorized.
The quickest and simplest method for authorizing Pervasive PSQL is using online or remote authorization. Whenever possible, try to authorize your Pervasive PSQL product using one of these methods. The Pervasive PSQL installation, for example, allows you to authorize online as part of the installation process.
*Note: Offline and telephone authorization are not available for Pervasive PSQL Vx Server.
Key Status, or State
The status of a product key is displayed in the License Administrator as the “state.” Key states include the following:
•
Active – key is authorized and available for use.
•
Inactive – key is no longer in use. This state is reserved for situations where the key is incompatible with the current engine. Examples would include previous versions of Pervasive PSQL, such as v10 and prior on v11, or a Workgroup key on a Server engine, or 32 bit key on a 64-bit engine.
•
Expired – key is no longer available for use. Temporary keys move to the Expired state once their evaluation period has passed.
•
Disabled – key is no longer available for use. If a key is disabled because of a failed validation, it can be restored to active by fixing the problem and then performing a validation on the key.
•
Failed Validation – key is usable but only for a set number of days. See Failed Validation and Failed-Validation Period.
Failed Validation and Failed-Validation Period
If a key fails validation, you have a set number of days to remedy the condition(s) that caused it to fail. This period of time, sometimes referred to as the “failed-validation period,” is reported as a date in the Expiration Date column of License Administrator. See GUI Visual Reference. If the condition for the failed validation is not corrected by the date, the key changes state to disabled.
After you implement changes to correct the failed validation, perform a Validation action. See To Perform a Validation. The validation, among other actions, verifies the current machine signature and key combination. If the conditions were corrected, the state of the key changes to active.
More than one condition at a time can cause a failed validation. You can correct what you think is the sole condition yet the key still remains in the failed validation state. If so, refer to the PVSW.LOG file for more information. That log file contains all of the conditions causing the failed validation. See Pervasive PSQL Event Log.
If the changes that caused the failed validation are due to intentional hardware upgrades performed without prior deauthorization of the key, the appropriate course of action is a repair of the key.
Repair
License Administrator provides the functionality to perform a repair on a key that is disabled or has failed validation. Moreover, it not only repairs the key, it automatically deauthorizes the key and then authorizes it again on the same machine.
You can perform a repair using either the graphical user interface (see License Administrator Graphical User Interface) or the command line interface (see License Administrator Command Line Interface).
If the problem is more significant than a change in hardware, for example, the machine on which a key is installed no longer boots, you cannot repair the key. In that case, contact support for assistance.
Increase User Count, Session Count, or Data In Use
Situations can arise in which you want to increase user count, session count, or data in use from the initial amount provided by the permanent product key. You increase the amount by authorizing an increase key. Multiple increase keys can be authorized on a product key.
The increase is immediately available when you authorize the key. A restart of the database engine is not required.
To authorize an increase key, you must already have a permanent product key present on the system. The software vendor ID number for an increase key must match the vendor ID number for an installed permanent key. Increase keys obtained from Pervasive Software are universal. That is, they are compatible with any permanent key from any vendor.
Also note the restrictions for key platforms listed in Tables 12 and 13.
Increasing User Count
You increase the user count by authorizing a user count increase (UCI) key. See To Authorize a Key and To Determine a Total User Count. UCI keys are provided by Pervasive Software or an application vendor.
If you deauthorize a permanent product key, all user count increase keys associated with that permanent key are also deauthorized. If you deauthorize a UCI key, only the user count increase associated with that UCI key is deauthorized.
Trial versions of the software include a trial license that have a set user count that cannot be increased.
Increasing Session Count Limit and Data In Use Limit
Pervasive Software or an application vendor offers a key to increase session count limit, data in use limit, or both. See To Authorize a Key, To Determine the Session Count Limit and To Determine the Data In Use Limit.
If you deauthorize the permanent product key, all increase keys associated with that permanent key are also deauthorized. If you deauthorize an increase key, only the session count increase or data in use increase associated with that key is deauthorized.
Trial versions of the software include a trial license that have a set value for session count and data in use that cannot be increased.
Key Platforms
The product key controls the conditions under which the product permits installation of, or access to, the database engine. The following tables summarize the restrictions based on platform for Windows and Linux. For example, if your key has a platform of "Win64," you can authorize that key on a database engine running only on a Windows 64-bit platform. The key is invalid for Windows 32-bit platforms and for any Linux platform.
Note that versions of Pervasive PSQL Server and Pervasive PSQL Vx Server are available for each bit architecture on each operating system. Pervasive PSQL Workgroup is a 32-bit product that runs only on Windows.
Table 12
Restrictions Pertaining to Windows Platforms
Key Platform
Pervasive PSQL Server
Pervasive PSQL Vx Server
OS Bit Architecture
 
Windows32
Windows64
32-bit
64-bit
Any
* 
* 
* 
* 
Windows
* 
* 
* 
* 
Win32
* 
 
* 
*1
Win64
 
* 
 
* 
1The Windows 32-bit version of Pervasive PSQL Server or Pervasive PSQL Vx Server can be installed on a Windows 64-bit machine but must run under the Windows-on-Window (WOW) execution layer.
Table 13
Restrictions Pertaining to Linux Platforms
Key Platform
Pervasive PSQL Server
Pervasive PSQL Vx Server
OS Bit Architecture
 
Linux32
Linux64
32-bit
64-bit
Any
* 
* 
* 
* 
Linux
* 
* 
* 
* 
Linux32
* 
 
* 
*1
Linux64
 
* 
 
* 
1The Linux 32-bit version of Pervasive PSQL Server or Pervasive PSQL Vx Server can be installed and run on a Linux 64-bit machine.
Message Logging
Messages pertaining to licensing are logged to the various logging repositories used by Pervasive PSQL, such as Notification Viewer. See Pervasive PSQL Message Logging.