Configuration Changes

Show this topic in Library frames

Changes made to configuration for Pervasive.SQL 9 include the following:

I*net Data Server Removed

5.x Files Support Reduced

Configuration Settings Not Manually Adjustable

Configuration Settings With Modified Defaults

Configuration Settings With Modified Values

Configuration Settings Not Requiring an Engine Restart

Configuration Settings That Dynamically Increase

Windows 16-bit Client Configuration

I*net Data Server Removed

I*net Data Server (IDS) is no longer a separately installable component of Pervasive.SQL. Most of the features that were part of IDS are now integrated into the main product. With the removal of the IDS components, you have the following considerations:

Environment Configuration

Application Changes

Environment Configuration

If your client/server environment previously used IDS, you must make the changes discussed in the following table to reconfigure the environment.

Table 1-1 Reconfiguration Required to Transition from an IDS Environment
Area	IDS Environment	Transition Task
Accessing the server engine	IDS server and client components had to be installed and configured. All of the settings except for USE IDS have been removed. The Use IDS setting now just specifies file location mapping based on information in the text file `idshosts`. See Use IDS in Advanced Operations Guide.	Ensure that Use Remote MicroKernel Engine is set to "On" (the default). See Use Remote MicroKernel Engine in Advanced Operations Guide. The remote access method now uses the Network Services Layer (NSL) to access the server.
Using encryption	The IDS client and server used compression to keep the data from flowing across the network as text. Pervasive.SQL currently does not implement compression but does use encryption.	Enable encryption on either the client, the server or both. By default, both client and server use encryption if the other partner requires it. See Wire Encryption and Wire Encryption Level , both in Advanced Operations Guide.
Specifying user names and passwords on the client	IDS handled its own security involving user names and passwords with the settings IDS Username and IDS Password. Both of these setting have been removed. User name and password were stored as plain text. The same information would be used by all users on the IDS system. The same user name and password needed to be valid on all the IDS servers accessed.	The security model for Pervasive.SQL has changed. Enabling security avoids the requirement for port 139 to be open for authentication from a Windows client to a Windows server, thus allowing access over the Internet. See Pervasive.SQL Security in Advanced Operations Guide. With security enabled, the client must provide a user name and password for database access. Select one, or a combination of, the following methods to accomplished this. The application can specify the user name and password by using a Btrieve URI. See Database URIs in Pervasive.SQL Programmer's Guide, which is part of the Pervasive.SQL software development kit (SDK). The user name and password information can be stored in the registry. See pvnetpass in Pervasive.SQL User's Guide. The user can be prompted for the user name and password. See Allow Client-stored Credentials and Prompt for Client Credentials , both in Advanced Operations Guide.
Creating a database	Using the IDS server IDS Setup program, an IDS administrator could set up various database sets. For each set, the administrator could specify the path for Read Only, Write Only, and Full Access.	Use the PCC to create a new database. See To create a new database in Advanced Operations Guide. Add multiple paths for the data file locations. See Database Properties in Advanced Operations Guide.
Securing a database	If security was specified in the IDS Setup program, the Data Server Security program allowed Groups or Users to be added who had Read Only, Write Only or Full Access privileges. IDS allowed only use of operating system users and groups.	Security may be applied to the database through the database properties dialog. You may then add groups and users, each with specified privileges. Note that you may define users and groups for the database, use the operating system users and groups, or a mixture of the two. See Pervasive.SQL Security in Advanced Operations Guide.
Configuring the network	The IDS server allowed an administrator to configure the server to be multihomed. The server could listen on all IP addresses available on the system or listen on a particular IP address. Multihomed was the default. The IDS server listened on port 2441.	The Pervasive.SQL server also allows an administrator to configure the server to be multihomed. Multihomed is the default. See Listen IP Address and TCP/IP Multihomed , both in Advanced Operations Guide. The Pervasive.SQL Communication Manager listens on port 3351. For remote access to occur, any firewalls and routers must allow access to port 3351. Port 2441 is no longer needed.
Specifying an acknowledge interval	The IDS server allowed an administrator to configure a time period that the server would wait before verifying that an inactive user was still present.	If this type of functionality is desired, you must enable AutoReconnect for both the database engine and the clients. See Pervasive Auto-Reconnect in Advanced Operations Guide.
Logging connection and disconnection activity	The IDS server allowed for logging of connection and disconnection activity.	Pervasive.SQL currently does not provide the logging of connection and disconnection activity.
Prompting for database set names	The IDS server allowed the following: prompting the ActiveX and Java Class Library (JCL) clients for the database name publishing the names of the configured database sets to those clients.	Pervasive.SQL currently does not provide the prompting for database set names.

Application Changes

The removal of IDS may require some changes to your application. The following effects should be noted.

IDS Name and IDS Password configuration parameters have been removed. The database engine handles all security.

Optionally, you may want to convert IDS PIDS protocol strings. The client requester now converts PIDS string to the URI security format.

Optionally, you may still use the idshosts file if you choose.

Note
Pervasive.SQL Server 8.5 or later is required if you set Use IDS to "On" or if your legacy applications pass file location information in the format of a PIDS URL. The requester uses database URIs to represent the IDS information. Database URIs were added with Pervasive.SQL 8.5.

If Use IDS is set to "On," you must also set Use Remote MicroKernel Engine to "On." Use Remote MicroKernel Engine is "on" by default.

See Use IDS and Use Remote MicroKernel Engine , both in Advanced Operations Guide.

Security

See Pervasive.SQL Security in Advanced Operations Guide for the types of database security.

The pvnetpass utility may be used to manage user ids and passwords for remote servers to which your client connects. See pvnetpass in Pervasive.SQL User's Guide.

A user name and password are needed only if other authentication methods fail, or if database security is enabled and requires a database user ID and password.

Conversion of PIDS Strings

If you choose, you may convert PIDS URL strings in your applications to the BTRV URI format. Such conversion is optional because the client requester automatically converts PIDS strings to the URI format.

For example, the format of the PIDS URL is PIDS://<servername | IP address>[:<dataset>]/<filepath>. The requester converts this to BTRV://@host/dbname?dbfile=filename.

The conversion of parameters corresponds as follows:


PIDS	BTRV
server_name or IP address	host
dataset	dbname
filepath	filename

See Database URIs in Pervasive.SQL Programmer's Guide, which is part of the Pervasive.SQL software development kit (SDK).

Idshosts File

Typically, an application provides its own file location information. As an alternative, IDS provided file location mapping based on information in a text file, idshosts. You may still use the idshosts file if you choose by setting the "Use IDS" configuration property to "on." Note, however, that performance is slower when the idshosts file is used.

Refer to the comments in the idshosts file itself for examples of how to map file locations. See also Use IDS in Advanced Operations Guide and Using the idshosts File in Advanced Operations Guide.

5.x Files Support Reduced

This release deprecates support for the version 5.x file format. The Pervasive.SQL 9 engine will read version 5.x format files, but will not write to them.

The previous release of Pervasive.SQL can read and modify 5.x format files. With Pervasive.SQL 9 it is no longer possible to modify 5.x format files. If you have files in 5.x format, you will have to rebuild them to a newer file format to update them.

The following effects should be noted:

5.x format files will be opened read-only. Any attempt to write to a 5.x format file will fail with status 46.

Create operation will fail if the format specified is 0500 or less. The error code returned is 41 (Operation Not Allowed).

The File Version engine setting can no longer be set to 0500.

For more information about this topic, see the following in Advanced Operations Guide:

Rebuild Utility Concepts

Create File Version

Also, refer to the following status codes:

41: The MicroKernel does not allow the attempted operation.

46: Access to the requested file is denied.

Configuration Settings Not Manually Adjustable

The following configuration settings are no longer manually adjustable. The "Change" column in the following table explains why.

Table 1-2 Configuration Settings Not Manually Adjustable
Name	Type	Change
Brouter Communication Buffer Size	Server (NetWare)	Set internally
Communication Buffer Size	Server	Set internally
Compress IDS Data	Client	IDS removed from product
IDS Password	Client	IDS removed from product
IDS Username	Client	IDS removed from product
MKDE Communication Buffer Size	Server	Set internally
Read Buffer Size	Server	Set internally
Supported Protocols	Linux server and client	Set internally
Target Engine	Client	Obsolete

Configuration Settings With Modified Defaults

The following configuration settings have modified default values.

Table 1-3 Configuration Settings With Modified Defaults
Name	Type	New Default	Refer To Advanced Operations Guide
Embedded Spaces	Client	On	Embedded Spaces
Splash Screen	Client and Client 16-bit	Off	Splash Screen Splash Screen

Configuration Settings With Modified Values

The following configuration settings have modified values.

Table 1-4 Configuration Settings With Modified Values
Name	Type	Change	Refer To Advanced Operations Guide
Create File Version	Server	9.x added 5.x removed	Create File Version
Supported Protocols	Server Client Client 16-bit	Vendor names removed from protocols	Supported Protocols Supported Protocols Supported Protocols

Configuration Settings Not Requiring an Engine Restart

The following server configuration settings no longer require that you restart the database engine for the setting to take effect.

Table 1-5 Configuration Settings Not Requiring an Engine Restart
Name	Refer To Advanced Operations Guide
Allow Client-stored Credentials	Allow Client-stored Credentials
Create File Version	Create File Version
Initiation Time Limit	Initiation Time Limit
Max MicroKernel Memory Usage	Max MicroKernel Memory Usage
Operation Bundle Limit	Operation Bundle Limit
Prompt for Client Credentials	Prompt for Client Credentials
System Data	System Data

Configuration Settings That Dynamically Increase

The configuration setting Communication Threads now dynamically increases up to the maximum value allowed. For Window and Linux platforms, the maximum is 1,024. For NetWare, the maximum is 200.

See Communications Threads .

Windows 16-bit Client Configuration

You now manually configure the settings for a Windows 16-bit client requester in the file BTI.INI. Windows 16-bit clients can no longer be configured through PCC.

See Win16 Client Configuration Parameters in Advanced Operations Guide.