About This Manual

This manual contains information about installing the Pervasive.SQL V8 database system. Pervasive.SQL V8 is a complete database system, providing the best of both worlds. It combines a transactional system designed for high-performance data handling and improved programming productivity with an embeddable and scalable relational system.

This manual also contains information about common installation pitfalls, general network protocol information, and Pervasive.SQL V8 components.

For information about configuring Pervasive.SQL V8, see Advanced Operations Guide.

Prev
Check for Revisions 		Next
Who Should Read This Manual


Who Should Read This Manual

This manual provides information for users who install and run Pervasive.SQL Workgroup edition.

Pervasive Software would appreciate your comments and suggestions about this manual. As a user of our documentation, you are in a unique position to provide ideas that can have a direct impact on future releases of this and other manuals. If you have comments or suggestions for the product documentation, post your request at http://www.pervasive.com/devtalk or send e-mail to docs@pervasive.com.

Prev
About This Manual 		Up
Check for Revisions 		Next
Manual Organization


Manual Organization

This manual is arranged in the order of the main installation sequence. You complete the installation by following the chapters in order. Getting Started With Pervasive.SQL is divided into the following sections:

Getting Ready to Install

  • Chapter 1—Welcome to Pervasive.SQL

    This chapter describes the components and documentation that come with Pervasive.SQL V8.

  • Chapter 2—Preparing to Install Pervasive.SQL

    This chapter discusses important preparations that you should undertake before attempting to install Pervasive.SQL V8 .

  • Chapter 3—Pervasive.SQL and Terminal Services

    This chapter describes how to use Pervasive.SQL V8 with Terminal Server Products.

Installing the Engine

  • Chapter 4—Installing Pervasive.SQL with No Previous Installation

    This chapter describes how to install Pervasive.SQL V8 for the first time on Windows NT, 2000, XP or Windows 98/ME.

  • Chapter 5—Upgrading Your Pervasive.SQL Installation

    This chapter describes how to upgrade a previous version of Pervasive.SQL on Windows NT, 2000, XP or Windows 98/ME.

Customizing Pervasive.SQL Workgroup

  • Chapter 6—Network Settings

    This chapter describes how to configure your network for use with Pervasive.SQL Workgroup.

  • Chapter 7—Client Network Configuration

    This chapter describes how to configure your client network settings for use with Pervasive.SQL Workgroup.

  • Chapter 8—Application Configuration Scenarios

    This chapter describes different application configurations for special scenarios.

  • Chapter 9—Using the DOS Requesters

    This chapter describes how to install and configure the DOS requesters.

  • Chapter 10—Configuring the Workgroup Engine

    This chapter describes how to configure Pervasive.SQL Workgroup using the Gateway Locator utility.

After Installation

  • Chapter 11—Connecting Clients to a Pervasive.SQL Database

    This chapter steps through a few procedures using the Pervasive Control Center, including connecting to a database and retrieving some data.

  • Chapter 12—Installation Troubleshooting

    This chapter outlines some common problems that can occur when installing and how to resolve them. It also provides information on Pervasive.SQL V8 tools that aid in diagnosing problems. This chapter gives contact information for Pervasive.SQL support for the case that you do not find the answer to your problem.

  • Chapter 13—Additional Resources

    This chapter describes online resources for help and provides contact information for Pervasive Software.

Supplemental Information

  • Appendix A —Introduction to Networking

    This appendix provides general information about establishing a network and running a Pervasive.SQL Workgroup environment.

This manual also contains an index.

Prev
Who Should Read This Manual 		Up
Check for Revisions 		Next
Conventions


Conventions

Unless otherwise noted, command syntax, code, and examples use the following conventions:
CASE | Commands and reserved words typically appear in uppercase letters. Unless the manual states otherwise, you can enter these items using uppercase, lowercase, or both. For example, you can type MYPROG, myprog, or MYprog.
Bold | Words appearing in bold include the following: menu names, dialog box names, commands, options, buttons, statements, etc.
Monospaced font | Monospaced font is reserved for words you enter, such as command syntax.
[ ] | Square brackets enclose optional information, as in [log_name]. If information is not enclosed in square brackets, it is required.
| | A vertical bar indicates a choice of information to enter, as in [file name | @file name].
< > | Angle brackets enclose multiple choices for a required item, as in /D=<5|6|7>.
variable | Words appearing in italics are variables that you must replace with appropriate values, as in file name.
. . . | An ellipsis following information indicates you can repeat the information more than one time, as in [parameter. . . ].
::= | The symbol ::= means one item is defined in terms of another. For example, a::=b means the item a is defined in terms of b.

Prev
Manual Organization 		Up
Check for Revisions 		Next
Getting Ready to Install


Getting Ready to Install

Prev
Conventions
Check for Revisions 		Next
Welcome to Pervasive.SQL


Welcome to Pervasive.SQL

A Basic Introduction to Pervasive.SQL V8

Thank you for purchasing Pervasive.SQL V8. We are confident that you will find Pervasive.SQL V8 to be the very best high performance, low maintenance database engine on the market.

This chapter contains the following topics:

  • About Pervasive.SQL
  • About Pervasive.SQL Workgroup
Prev
Getting Ready to Install
Check for Revisions 		Next
About Pervasive.SQL


About Pervasive.SQL

Pervasive.SQL V8 is a reliable, low-maintenance, high-performance database management system (DBMS). Thousands of companies around the world license Pervasive.SQL and distribute it as the underlying data storage program for their data-intensive software products. These companies see no reason to build their own DBMS or license from a competitor once they experience the ease-of-use, reliability, and value offered by Pervasive.SQL.

No matter whether you received Pervasive.SQL with another product or purchased it yourself, this section explains a little about the product and why it is right for you.

If you would like to read a detailed discussion of Pervasive.SQL architecture and interfaces, please refer to Pervasive Products and Services.

Competitive Advantages

Pervasive.SQL provides a number of advantages over other products available on the market. Here are just a few:

  • Lowest total cost of ownership. An independent study conducted by Aberdeen Group concluded that no major database product can match Pervasive.SQL's low total cost of ownership. How do we do it? See the next bullet.
  • No Database Administrator (DBA) required. You can look in the newspaper any day of the week and see classified ads for Oracle, Sybase, or SQL Server database administrators, with sky-high salaries. Pervasive.SQL offers the unique Zero Database Administrator, or Z-DBA, architecture. Its easy-to-use tools, bulletproof installation, and set-it-and-forget-it simplicity make it the perfect workhorse for desktop, workgroup, and departmental applications.
  • Scalable from the desktop to the Web. Pervasive.SQL is available in two editions: the Ultra-light Desktop database engine supports applications running locally on the same computer as the engine and comes with a five-user license; and the Server engine starts with a 10-user license and scales to hundreds of concurrent users, including intranet and extranet applications. Upgrading to another configuration requires no changes to the supported application, just plug-and-play with the new database engine.
  • Cross-platform support. Unlike some competitors, Pervasive.SQL does not lock you in to a single platform. Pervasive.SQL databases are binary-compatible and supported across Microsoft Windows, Novell NetWare, and several varieties of Linux. No matter where your data is or where it is going to be, Pervasive.SQL is there for you.
  • Big database features at a small price. Pervasive.SQL offers full security, encryption, management and monitoring tools, and a host of other features you would expect to see in more expensive DBMS products.
  • Legendary stability and reliability. There's no doubt why 70% of the Windows desktop accounting market uses Pervasive.SQL as the underlying database of choice. When you've got to manage important data, you go for the database engine that won't let you down.

Relational or Transactional Access

Pervasive.SQL offers an architecture that is totally unique in the database management market. Our product allows you to access the exact same data through ODBC and OLE DB, supporting applications like Microsoft ASP, Excel, and Access, or through the lightning-fast transactional interface called Btrieve. ODBC allows you to do complex reporting and data mining, while Btrieve provides massive throughput when you need the ability to view, update, or create millions of records a day.

It is the choice of each application vendor as to which interfaces they use. If you want to know which access methods are used in your application, ask your application vendor.

Prev
Welcome to Pervasive.SQL 		Up
Check for Revisions 		Next
About Pervasive.SQL Workgroup


About Pervasive.SQL Workgroup

This section provides some basic information about Pervasive.SQL Workgroup. For a detailed discussion of Pervasive.SQL architecture, please refer to Pervasive Products and Services.

If you would like more information about what comes in your product and what gets installed, please see Chapter 2, Preparing to Install Pervasive.SQL.

Purpose

You have purchased Pervasive.SQL Workgroup. This version of the product ships with a five-user license and is designed to support single-user or small workgroup installations.

Pervasive.SQL Workgroup offers the same level of reliability and features as the Server engine. The only differences lie in networking and performance in mid- and large-size environments.

Pervasive.SQL Workgroup offers a flexible approach to accessing data on remote servers, allowing a variety of small network configurations. If you have data files on a remote file system with no database engine present, you can configure Pervasive.SQL Workgroup so that a particular engine is always used to access the remote data, or you can set it up so that the first engine to access the files then "serves" those files until there are no more requests for data. After this point, again the first engine to access the files then owns the files while requests are coming in.

Where to Install

Pervasive.SQL Workgroup can be installed on the same computer where the database files are located, or it can be installed on other computers to access the data over the network. All client components are installed with Pervasive.SQL Workgroup, so even if you access remote files through another Workgroup engine, you do not need to install the client.

In the case of web applications, the client must be installed on the same computer as the web server. Multiple web server platforms require a client on each platform.

User Licenses

Pervasive.SQL Workgroup engines are installed by default with a five-user license. If you require a license that allows more concurrent users, consider the Pervasive.SQL Server engine, which is shipped with a ten-user license and is capable of scaling to hundreds of concurrent users with the purchase of additional licenses.

Features

All Pervasive database engines offer the same powerful feature set and full-functioned support for programming interfaces. All engine editions are plug n' play compatible, requiring no application changes to switch from one engine to another. Data files are binary-compatible across all supported platforms.

The chart below shows the major differences between the different editions of the product.
Table 1-1 Comparison of Server and Workgroup Features
Feature | Server | Workgroup
Supports Btrieve, ODBC, OLE-DB, JDBC, PDAC and ActiveX interfaces | ü | ü
Full-featured relational support (online backup, security, referential integrity, management tools, and so on) | ü | ü
Binary compatible data files across all platforms and engine editions | ü | ü
Easy plug n' play upgrading, no application changes required | ü | ü
Comes with online documentation | ü | ü
Can access data on a file server where no database engine is installed |  | ü
Engine runs on Windows | ü | ü
Engine runs on NetWare | ü |
Engine runs on Linux | ü |
Multi-user for small groups | ü | ü
Scales to thousands of users | ü |
Extranet license available | ü |

Prev
About Pervasive.SQL 		Up
Check for Revisions 		Next
Preparing to Install Pervasive.SQL


Preparing to Install Pervasive.SQL

Preparation Needed for Pervasive.SQL V8 Workgroup Installation

This chapter prepares you to install Pervasive.SQL V8 by providing an overview of major components, a list of what items are installed during the installation procedure, and providing a detailed checklist to gauge your readiness to proceed with the Pervasive.SQL V8 installation.

This chapter contains the following sections:

  • Installation Overview
  • Installation Checklist
Prev
About Pervasive.SQL Workgroup
Check for Revisions 		Next
Installation Overview


Installation Overview

This section provides an overview to the components that make up Pervasive.SQL V8. Also included in this section is information on the files included in the different types of installation.

Major Components of Pervasive.SQL V8

Pervasive.SQL V8 consists of the following components:

Pervasive.SQL V8 Database Engine

Pervasive.SQL V8 consists of two database sub-engines:

  • MicroKernel Database Engine (MKDE), which provides Btrieve/MicroKernel API support for Pervasive.SQL applications
  • SQL Relational Database Engine (SRDE), which provides ODBC/SQL API support for Pervasive.SQL applications

Note
The Pervasive.SQL V8 stand-alone client install is not included in the Workgroup edition of Pervasive.SQL V8. Each installation of Workgroup edition includes all client components, so a separate install is not needed.

Client

Requesters that allow you to access the server-based MicroKernel from a DOS or Windows 9X/NT/2000 client.

  • The 16-bit requesters used in DOS clients are Btrieve requesters only and have no relational access.

Pervasive.SQL V8 Utilities

Pervasive.SQL V8 includes a suite of useful utilities for every phase of database management from engine installation and configuration to data maintenance. They include the following:

  • Pervasive System Analyzer (PSA)
  • Pervasive Control Center (PCC)
  • Configuration
  • Monitor
  • Function Executor
  • Maintenance
  • SQL Data Manager
  • Table Designer
  • Rebuild
  • License Administrator
  • ODBC Administrator
  • Gateway Locator
Wizards

As part of the tools available in PCC, a suite of wizards provide an interactive way to assist you in database development, maintenance, and manipulation. Wizards available in Pervasive.SQL V8 include the following:

  • Create Database
  • Drop Database
  • Check Database
  • Import Data
  • Export Data
  • Null Conversion
  • Create Table
  • Drop Table

Printed Documentation

If you received a boxed version of Pervasive.SQL V8, your package contains a printed copy of Getting Started With Pervasive.SQL (Workgroup Edition) and the Status Codes and Messages Quick Reference card. You can order a complete hardcopy set of the manuals through the Pervasive Software Sales Team.

Online Documentation

In addition to context-sensitive help for the utilities, the complete Pervasive.SQL V8 online documentation set is available in CHM or HTML formats, depending on your operating system and your available browser.

Documentation Titles

The following titles are included in the online library and are available in hardcopy:

  • Getting Started with Pervasive.SQL V8 (Server and Workgroup Editions)—helps you to get Pervasive.SQL running with installation, setup, and basic configuration information based on your operating environment.
  • What's New (for latest release)—contains information about new features and enhancements and describes the changed behaviors of the current product relative to the most recent previous release.
  • Pervasive Products and Services—provides an overview of Pervasive Software products and services, including support options and information regarding licensing and registration. This manual also describes the database and product architectures.
  • Pervasive.SQL User's Guide—gives basic information on the utilities provided with the Pervasive Control Center, including several interactive wizards designed to help you accomplish basic database tasks. This manual also contains information on the Unix version and the utilities available for that particular platform.
  • SQL Engine Reference—provides database programmers a complete reference guide to the SQL relational database language supported in Pervasive.SQL V8.
  • Advanced Operations Guide—explains tasks typically performed by Network or System Administrators, using various tools such as the Rebuild, Maintenance, Monitor, and Function Executor utilities.
  • Status Codes and Messages—lists the error and informational codes and messages that can be received when using Pervasive software.

Installation Options

Pervasive.SQL V8 offers Typical and Custom installation options. You can accept default installation parameters by selecting the Typical install. On the other hand, you can specify certain installation parameters by selecting the Custom install option. The following outlines the major differences in these two installation options.

Typical Setup Installation

The Typical installation is recommended for most users. This option takes default actions for most operations performed during the installation.

The Typical setup installs the following components:

  • Pervasive.SQL V8 Engine (including ODBC interface)
  • All possible requesters (MS-DOS, Win16 and Win32 requesters)
  • Utilities
  • Transactional and Relational interfaces
  • Client installation copies
  • Online documentation

Custom Setup Installation

Selecting Custom setup type allows you to specify the program folder name and select the components to install.

During a Custom setup, the following component is optional:

  • Online documentation

The default installation location for Pervasive.SQL V8 is C:\PVSW, assuming the Windows system drive is C.

Prev
Preparing to Install Pervasive.SQL 		Up
Check for Revisions 		Next
Installation Checklist


Installation Checklist

This section provides you with a checklist to prepare you for installation. Please use this checklist as a guide for a successful installation.

Quick Checklist

Each of the following bullet points is described in more detail in the sections that follow.

  • Your system hardware meets the minimum requirements (listed later in this chapter) to install Pervasive.SQL V8 Workgroup.
  • Your operating system is supported by Pervasive.SQL V8.
  • You have full administrative rights on the Windows system where you plan to install the product.
  • Your application vendor supports the Pervasive.SQL V8 engine.
  • Schedule the upgrade appropriately and perform the installation with care.
  • Licenses for older versions of the product cannot be migrated up.
  • Read the README file for important, late-breaking warnings and information.
  • If you are installing a downloaded version of Pervasive.SQL, do not place the install file in a location that is listed in the PATH environment variables, as this can cause issues with file copying during install. Place the setup files in a location such as the Windows TEMP directory.

Check the Hardware Requirements

Pervasive.SQL V8 Workgroup requires the following specifications:

  • Intel 486 processor or higher.
  • At least 32 MB of free memory.
  • Up to 35 MB of free space for system components and the installation, depending upon the installation options chosen.

Check the Software Requirements

Your operating system (and, optionally, version of Internet Explorer) must be supported by Pervasive.SQL V8. The following are supported:

  • Windows 98
  • Windows ME
  • Windows 2000 (SP1 or later)
  • Windows XP
  • Windows NT 4 (SP6A or later)
  • If you are installing onto a terminal server, see Chapter 3, Pervasive.SQL and Terminal Services.
  • To install the Workgroup engine, you need Internet Explorer version 4.01 SP2 or greater.
  • For the Pervasive.SQL utilities and online documentation, you need Internet Explorer 5.01 or greater.

Note
Internet Explorer 5.01 is required only for the utilities and online documentation. Internet Explorer 4.01 SP2 or greater is required to install the Pervasive.SQL Workgroup engine. See also the Pervasive.SQL README file for a list of Internet Explorer versions that may cause formatting and display problems with the online documentation.

Ensure Adequate Permissions

To install Pervasive.SQL V8 on Windows NT, 2000 or XP, you must have full administrative-level permissions on the machine where you will install the product. For information on granting administrative rights, please refer to Pervasive.SQL User's Guide.

Verify Compatibility of Vendor Applications

Contact your application vendor or review the documentation provided by your vendor to ensure that they support the Pervasive.SQL V8 engine version and mode that you want to install.

Schedule the Upgrade and Perform with Care

The installation and upgrade should be performed during a period of low use.

As with any significant software installation, be sure to back up any important files on the target hard drive, including data files, before you begin the installation.

If you are performing an upgrade, keep the installation media and instructions from the old installation, in the unlikely event that you need to fall back to the previous version of the product.

Installing to a Cluster

If you plan to install Pervasive.SQL to a clustered environment using either Microsoft Cluster Service or NetWare Cluster Services, please read the following in Advanced Operations Guide: Server High-Availability Support .

Check for Special Configuration Issues

Some default setting in Pervasive.SQL need to be adjusted if your configuration includes certain qualities. For example, the default settings need adjustment if you have:

  • Multiple network interface cards (NICs)
  • Files with Embedded Spaces

Please review Configuration for Special Installation Situations for these or other relevant issues, especially if you encounter problems after installation.

Read the README file

Pervasive Software strongly recommends that you read the information contained in the README file. This file contains important product news that could not be included in the product documentation but is essential to your installation and use of the product.

Prev
Installation Overview 		Up
Check for Revisions 		Next
Pervasive.SQL and Terminal Services


Pervasive.SQL and Terminal Services

How to Use Pervasive.SQL with Terminal Services

This chapter explains how to use Pervasive.SQL with Microsoft Terminal Server and Citrix MetaFrame. In general, you can use Pervasive.SQL on machines with either product in almost the same way as on a computer without remote access.

This chapter contains the following sections:

  • Overview
  • Licensing
  • Installation
  • Configuration and Runtime

Prev
Installation Checklist
Check for Revisions 		Next
Overview


Overview

Microsoft Terminal Services is a multisession environment that provides remote computers access to Windows-based programs running on a server. Citrix MetaFrame extends Windows Terminal Services with additional client and server functionality.

Supported Environments

You may install the Pervasive.SQL database engine in any of the following environments:

  • Windows NT 4 Terminal Server SP6a
  • Windows 2000 Terminal Server SP1
  • Windows NT 4 Terminal Server SP6a with Citrix MetaFrame 1.8
  • Windows 2000 Terminal Server SP1 with Citrix MetaFrame 1.8

Only one instance of the database engine may run on any terminal server platform. You cannot run separate copies of the database engine within two or more terminal sessions.

Prev
Pervasive.SQL and Terminal Services 		Up
Check for Revisions 		Next
Licensing


Licensing

Each terminal server client session counts as one user. Collectively, all applications that access the database engine and run on the same machine as the database engine also count as one user. You must purchase sufficient user count licenses to cover the number of users accessing each database engine. For example, if you have a 5-user license, you may not have more than 5 users accessing the database at once, whether they are connected through terminal sessions or remote database connections.

You may not use a terminal server as a method of bypassing the user count mechanism of the database engine.

Prev
Overview 		Up
Check for Revisions 		Next
Installation


Installation

To install Pervasive.SQL on a terminal server, you must be logged into the terminal server as a user with system administrator rights.

Windows NT Server

Prior to installation, you must switch the terminal server to install mode using the change user /install command. This ensures that the software is available to all users after installation. When the installation is complete, you set the terminal server back to runtime mode using the command change user /execute.

For more information about this command, see the Microsoft Knowledge Base article (especially the "Additional Notes" at the bottom of the article):

http://support.microsoft.com/?kbid=186504

Windows 2000 Server

Install Pervasive.SQL through Add New Programs (Start 4 Settings 4 Control Panel 4 Add/Remove Programs 4 Add New Programs). The operating system automatically handles the changing of terminal server modes.

Prev
Licensing 		Up
Check for Revisions 		Next
Configuration and Runtime


Configuration and Runtime

This section provides information pertaining to configuration.

Remote Configuration with PCC

You cannot use PCC through a terminal session to configure a remote database engine. You must use PCC at the terminal server console or through a standard remote connection to configure the database engine on the terminal server machine.

Terminal Server as Network Server

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.

Workgroup Engine Running as a Service

You may configure your server to run the Workgroup engine as a service. This allows the engine to start automatically when the operating system starts. A user is not required to log in to start the engine. Refer to Running the Workgroup Engine as a Service .

Prev
Installation 		Up
Check for Revisions 		Next
Installing the Engine


Installing the Engine

Prev
Configuration and Runtime
Check for Revisions 		Next
Installing Pervasive.SQL with No Previous Installation


Installing Pervasive.SQL with No Previous Installation

Instructions for First-time Workgroup Installation

This chapter contains procedures for installing the Pervasive.SQL V8 Workgroup engine when there is no previous installation of the product on your system. The chapter contains the following sections:

  • Before You Begin
  • Installing the Pervasive.SQL Workgroup Engine
  • Custom Installation Path
  • Common Questions After Installing Pervasive.SQL
  • Uninstalling Pervasive.SQL Workgroup
Prev
Installing the Engine
Check for Revisions 		Next
Before You Begin


Before You Begin

Before installing Pervasive.SQL V8, begin by reviewing the following documents for important information:

  • Chapter 2 , Preparing to Install Pervasive.SQL - This chapter provides important information including system requirements and platform specific notes that are relevant to your operation.
  • "What's New in Pervasive.SQL V8" - This document is included in your product package and contains information regarding the latest features and improvements in this release.
  • README file - This file is located on the distribution media and contains late-breaking product news that could not be included in the product documentation.

Installing Over Existing Pervasive Products

If you are installing over an existing Pervasive product, then please see Upgrading Your Pervasive.SQL Installation . This chapter is for installations where no Pervasive products currently exist.

Installation Tips

  • When installing Pervasive.SQL V8 for the first time on a system, Setup will check if all of the needed system files meet the minimum requirements. In some cases, these files are locked by the operating system and a reboot is required before Setup can continue. Click Yes to reboot the system. Setup is then automatically be restarted.

Note
It is strongly recommended that you reboot your system if you encounter this message. If you do not reboot your system, Setup will encounter failures during engine and utilities configuration.

  • If you have any trouble with the following installation, see Chapter 12, Installation Troubleshooting.

Accessing README file information

It is highly recommended that you review the README file to understand the latest warnings and critical notes regarding Pervasive.SQL V8.

Prev
Installing Pervasive.SQL with No Previous Installation 		Up
Check for Revisions 		Next
Installing the Pervasive.SQL Workgroup Engine


Installing the Pervasive.SQL Workgroup Engine

Note
If the installation fails before the program copies any files to the target installation directory, the installation log file (install.log) can be found in the directory specified by the %TEMP% environment variable. This directory is often c:\windows\temp or c:\winnt\temp.

To install Pervasive.SQL V8 on a Windows NT, 2000, XP, or 98/ME workstation

  1. Launch the installation program from your Windows workstation
    1. Insert the Pervasive.SQL V8 Workgroup CD in the CD-ROM drive of your Windows workstation.
    2. If the installation does not start automatically, click Start, select Run, and type drive:setup where drive is the drive letter of your CD-ROM device.

      Caution
      Do not launch the install using programs other than setup.exe. Some critical checks of your system configuration and some install settings are made using the setup.exe program.

Note
Please see Installation Tips regarding the Pervasive.SQL V8 Setup Reboot Required dialog box.

The installation Welcome screen appears. Click Next to proceed with the installation.

  2. Read and accept the Software License Agreement

Figure 4-1 Pervasive Software's Software License Agreement

Read the Pervasive Software License Agreement. Select the choice that indicates you accept the terms in the license agreement choice and click Next to continue the installation.

  3. Type or paste a license key into the License field, or type EVAL to install an evaluation license. Click Next to continue.

Figure 4-2 Applying the User Count License

  4. Select the Setup Type: Complete or Custom

Figure 4-3 Setup Type Dialog Box

Click Next to continue with installation.

Note About Complete Installation

The Complete installation, recommended for most users, takes default actions for most operations performed during the installation.

The Complete Workgroup installation installs the following components:

  • Pervasive.SQL V8 Engine, including the Transactional and Relational (ODBC) Interfaces
  • Utilities
  • Online documentation
  • Client requesters

No other components are needed or available.

Note About Custom Installation

The Custom installation is typically for advanced users; it lets you choose the components you want to install and specify the program folder location.

If you choose a custom install, skip now to Custom Installation Path .

  5. Verify your installation settings

Figure 4-4 Ready to Install

The default installation location for Pervasive.SQL V8 is C:\PVSW (assuming the Windows system drive is C:\).

If the displayed selections are correct, click Install to continue.

  6. Certain programs and services on Windows can interfere with the Pervasive.SQL installation process. The Pervasive.SQL installation program detects these programs if they are running during your installation and informs you so that you can stop the programs. Doing so ensures that your installation completes successfully.

    Skip to Step 2 if you do not see a screen similar to Figure 4-5.

Figure 4-5 Detection of Programs Running During Installation

There are two categories of programs detected by the installation program:

  • Programs that must be stopped in order to install Pervasive.SQL.

    An example of a program in this category is one that utilizes the Pervasive.SQL Workgroup engine.

  • Programs that may cause issues with installation and should probably be stopped in order to ensure an issue-free installation.

    Examples of programs in this category include such products as Microsoft Internet Information Service (IIS) and others that can potentially lock system files.

    If you want to continue the installation despite the possible conflict, click Ignore.

  7. Pervasive.SQL V8 copies the necessary files to complete your specified installation requirements.

    If you had a previous version of Pervasive.SQL on your system, Pervasive System Analyzer archives it before copying the updated Pervasive.SQL V8 files.

Figure 4-6 Setup Begins Copying Files

 Note
Only click Cancel if you want to stop installation and exit the Setup process.

  8. Your Pervasive.SQL V8 Workgroup installation is complete.

    The following dialog box informs you that the installation is complete.

Figure 4-7 Installation Complete Dialog Box

Click Finish.

  9. If installed files could not be copied because they were locked in memory, a reboot may be necessary at this point. Setup only prompts for a reboot if a locked file or some other event was detected that requires a reboot. Please reboot your system if prompted to do so in order to ensure proper operation of your Pervasive.SQL V8 product.

Figure 4-8 Installation Complete - Need Reboot

 Note
If you have any trouble with the installation, see Chapter 12, Installation Troubleshooting.

The install program modifies the PATH and CLASSPATH environment variables at the end of the installation process, if needed. These settings control how your Windows operating system finds Pervasive components. In Windows NT, these environment variables are stored in the Control Panel under the Environment tab on the System icon. In Windows 2000, these variables are stored in the Control Panel under the Advanced tab on the System icon.

Post Installation

  10. The Pervasive System Analyzer (PSA) launches its tests of the transactional and relational interfaces. These tests ensure that your database engine is working as expected after installation.
  11. Test the Transactional Engine

    PSA now performs a series of tasks to ensure that the transactional engine is working properly.

Figure 4-9 Transactional Engine Test

In the space provided, specify the samples subdirectory of the installation location, as shown. Then click Next to run the tests and see the results.

  12. View the Transactional Test Results

    PSA displays a check mark for each test that passes and an X for each task that fails during the transaction engine test. A summary report is also provided in the information window, as shown in the following figure.

Figure 4-10 Transactional Engine Test Results from PSA

If any of the tests fail, see Chapter 12, Installation Troubleshooting.

Once your transactional engine tests are successful, click Next to test the relational engine.

  13. Test the Relational Engine

    PSA now performs a series of tasks to ensure that the relational engine is working properly.

Figure 4-11 Relational Engine Test

Enter the Machine Name and Engine DSN for the engine data you want to test. The default values are your current machine name and the sample demodata database. These values should be used unless you specifically wish to test a different database. Click Next to run the tests and see the results.

  14. View the Relational Test Results

    PSA displays a check mark for each test that passes and an X for each task that fails during the relational engine test. A summary report is also provided in the information window, as shown in the following figure.

Figure 4-12 Relational Engine Test Results from PSA

If any of the tests fail, see Chapter 12, Installation Troubleshooting. If you want to view the PSA log file, it is named by default PSALog.txt and is located by default at <OSdrive>\Program Files\Common Files\Pervasive Software Shared\PSA, where <OSdrive> is the drive letter where your operating system is installed.

Once your relational engine tests are successful, click Next.

  15. Your Pervasive.SQL V8 Workgroup installation and verification tests are complete.

    Thank you for choosing Pervasive.SQL.

What to do Next

Skip the next section for custom installations and see Common Questions After Installing Pervasive.SQL .

Prev
Before You Begin 		Up
Check for Revisions 		Next
Custom Installation Path


Custom Installation Path

This section describes how to customize your installation of Pervasive.SQL V8.

  1. Click on a feature's icon to display the installation choices.

    For example, the following image shows the choices if you click on the Client icon.

Figure 4-13 Example of Installation Choices

  2. Decide how you want to install the program features.
    Installation Choice
    Meaning
    This feature will be installed on local hard drive.
    This feature, and all subfeatures, will be installed on local hard drive.
    The feature's components, and subfeatures if you choose, are installed on the machine running the installation program.
    This feature will not be available.
    The feature's components are excluded from the installation.

Excluding Features

You may exclude only the full set of utilities from the Workgroup installation.

You may not exclude the minimum set of utilities. The minimum set includes the Password Utility and the following command-line interface (CLI) utilities: Maintenance, Rebuild, and License Administrator.

If you exclude utilities, you will be unable to configure your Pervasive.SQL Server product. The product is installed using all default values. In addition to no configuration ability, other restrictions apply. For example, no wizards will be available. We recommended that you include the utilities unless you are certain that you do not require the functionality provided by them.

The following utilities are not installed if you exclude them.

  • Pervasive Control Center (PCC)
  • Table Designer and SQL Data Manager
  • All wizards
  • Monitor, GUI Maintenance, and GUI Rebuild
  • GUI License Administrator
  • Click on the desired installation choice.
  • If desired, change the location where the Pervasive.SQL Workgroup product and its features are installed.

    The default installation location is C:\PVSW, assuming the Windows system drive is C. To specify a different location for the installation, click Change, specify a location, then click OK.

    You may select only one installation location for the entire product. The Change button is disabled for a feature if you choose not to install that feature.

  • If desired, click on a feature to check the amount of storage space it requires.

    The space required appears on the right:

Figure 4-14 Location of Space Required Values

  6. If desired, check the amount of storage space available on the physical drives.

    Click on a feature, then click Space. The resulting dialog shows you by storage volume, the total disk space, the available disk space, the space required for the feature, and difference between the available space and space required. Click OK after you finish checking storage capacity.

  7. Click Next.

    A dialog appears that informs you the installation program is ready to begin installing files. At this point, if you want, you may click Back to change or review any of the installation settings, or click Cancel to exit the installation program. After you click Install, you may still exit the installation, but you will be unable to change or review settings.

The custom path now rejoins the Complete installation path. See Step 6 .

Prev
Installing the Pervasive.SQL Workgroup Engine 		Up
Check for Revisions 		Next
Common Questions After Installing Pervasive.SQL


Common Questions After Installing Pervasive.SQL

This section contains information that you should read after running the installation program. If you are having problems with your installation, go to Chapter 12, Installation Troubleshooting or get help online from our Knowledge Base website at http://support.pervasive.com/eSupport.

If you are installing the Workgroup engine, you must install it on every computer that is expected to share data within your workgroup. Because every computer must have the Workgroup engine installed, there is no need to install the client software separately as required for the Server engine.

How Do I Read the Online Documentation?

Pervasive.SQL V8 documentation for Win32 platforms is in Microsoft HTML Help format. To read the documentation, select Start 4 Programs 4 Pervasive.SQL V8 4 Documentation 4 Pervasive.SQL V8 from the Windows Start menu.

You can also view the documentation in the form of Adobe Acrobat (PDF) files. These PDF files, and an installation program for an Acrobat reader, are available on the Pervasive.SQL V8 (Server Edition) CD-ROM.

There is also a README file on the distribution media that has the latest changes and additions to Pervasive.SQL V8.

What User License Was Installed with the Product?

The Pervasive.SQL V8 installation program automatically installs a five user permanent license when you install a Workgroup engine product.

There is no configuration necessary for the license. After installation, you can use the License Administrator utility to view your installed licenses. See the Pervasive.SQL User's Guide for more information on the License Administrator utility.

What Files Were Installed As Part of Pervasive.SQL V8 (Workgroup Edition)?

Once installed, Pervasive.SQL V8 files reside in the following default directory structure.
\WINNT\SYSTEM32 (on WinNT/Win2000/WinXP systems) \WINDOWS\SYSTEM32 (on Win98 systems) |  | Microsoft system files Pervasive glue dlls
\Program Files\Common Files\Pervasive Software Shared
 | \PSA | Pervasive System Analyzer
 | \DOC | Online documentation
 | \PVSWCORE | Pervasive Services
\PVSW |  |
 | \BIN | Pervasive.SQL engines, requesters, and utilities
 | \DEMODATA | Contains sample database
 | \SAMPLES | Contains the sample database SAMPLE.BTR and UPPER.ALT, a sample Alternate Collating Sequence

Prev
Custom Installation Path 		Up
Check for Revisions 		Next
Uninstalling Pervasive.SQL Workgroup


Uninstalling Pervasive.SQL Workgroup

The uninstall program removes all Pervasive.SQL Workgroup components from your system that were added by the installation program.

The uninstall program does not remove the following:

  • Databases that you create under the Pervasive.SQL Workgroup installation directory (which is C:\PVSW by default).
  • DSNs and database names associated with those databases.
  • Databases in locations other than the Pervasive.SQL Workgroup installation directory.
  • DSNs and database names associated with those databases.

To uninstall Pervasive.SQL Workgroup:

  1. Access Add/Remove Programs from Control Panel on your Windows operating system.
  2. Click Pervasive.SQL Workgroup in the list.
  3. Click the button to remove a program. The button may be labelled Add/Remove or Remove.

    The program to uninstall Pervasive.SQL Workgroup begins.

  4. Click Next.
  5. Click the Remove option.

Figure 4-15 Uninstall Remove Option

  6. Click Next.

    A dialog appears that informs you the program is ready to begin removing Pervasive.SQL Workgroup. At this point, if you want, you may click Back to change or review any of the settings, or click Cancel to exit the uninstall program.

  7. Click Remove to begin the uninstall process.
  8. Click Finish when the uninstall program completes.
  9. Reboot your system if prompted to do so.
Prev
Common Questions After Installing Pervasive.SQL 		Up
Check for Revisions 		Next
Upgrading Your Pervasive.SQL Installation


Upgrading Your Pervasive.SQL Installation

Instructions for Upgrading an Existing Pervasive.SQL Installation

This chapter contains information specific for upgrading your current Pervasive product installation to Pervasive.SQL V8.

This chapter contains the following sections:

  • Before You Begin
  • Upgrading to Pervasive.SQL Workgroup Engine from Earlier Pervasive.SQL Versions or Btrieve 6.x
  • Custom Installation Path
  • Common Questions After Installing Pervasive.SQL

Throughout this document, when an explicit version number is not specified (for example: Pervasive.SQL 7, Pervasive.SQL 2000, or Pervasive.SQL V8), all versions are included.

Prev
Uninstalling Pervasive.SQL Workgroup
Check for Revisions 		Next
Before You Begin


Before You Begin

Before upgrading to Pervasive.SQL V8, begin by reviewing the following documents for important information:

  • Chapter 2 , Preparing to Install Pervasive.SQL - This chapter provides important information including system requirements and platform specific notes that are relevant to your operation.
  • "What's New in Pervasive.SQL V8" - This document is included in your product package and contains information regarding the latest features and improvements in this release.
  • README file - This file is located on the distribution media and contains late-breaking product news that could not be included in the product documentation.

Considerations

Once you have reviewed the latest product information, review this list of considerations to complete your upgrade installation preparation.

  • Pervasive.SQL Applications - Be aware of what applications you have currently using previous versions of Btrieve or Pervasive.SQL in your environment. Don't forget to include both client and server-based applications, such as ArcServe.
  • Vendor-Specific Information - Be sure and check with your application vendors for any specific information regarding their product with Pervasive.SQL.
  • TCP/IP Protocol - DOS applications require different requesters, preferably BTRBOX95, BTRDRVR, or BREQTCP.
  • New Features and File Rebuilding - In order to make use of all the new version features, you must rebuild your data files so that they use the newest version file format. Pervasive.SQL Advanced Operations Guide includes a chapter that details using the Rebuild Utility to rebuild your data files, if you would like to take advantage of newer features.
  • Back Up Data Files - Make sure you have a current backup of all your data files prior to beginning upgrade installation

Platform Notes for Windows

This section contains installation information specific to the Windows NT and Windows 2000 platforms.

  • If you run with Advanced Power Management, disable it while installing Pervasive.SQL V8. The power management can cause a Pervasive.SQL installation to fail if the server is suspended during the install. In Windows NT, the advanced power management setting is located on the Power icon on the Control Panel. In Windows 2000, this setting is located in the Control Panel under the APM tab of the Power Options icon.

Migration of Existing Configuration Settings

During the installation process, all of your existing engine configuration values are migrated to the new engine, with several exceptions. The exceptions are documented in Table 5-1.
Table 5-1 Configuration Setting Values not Migrated to V8
Configuration Setting | Value in V8
Server4Debugging4Trace File Location | C:\pvsw\bin\mkde.tra [default]; or bin\mkde.tra file in selected installation directory.
Server4Directories4 Transaction Log Directory | C:\pvsw\bin\mkde\log [default]; or bin\mkde\log subdirectory of selected installation directory.
Server4Compatibility4 Create File Version | 8.x. By default, new data files are always created in the most recent file format.
Server4Memory Usage4 System Cache | Off. With the addition of Level 2 database cache in V8, the system cache should not be used.
Server4Data Integrity4 Transaction Durability | Off. With the addition of a new setting, Transaction Logging (default: On), Transaction Durability is not needed to ensure multi-file transaction atomicity and data integrity. If your application requires true Transaction Durability, you will need to use Configuration to turn this setting On.

Installing Over Existing Pervasive Products

  • If you are upgrading from older product versions such as Btrieve 6.15 and wish to make use of all the new version features, you must rebuild your data files so they use the v8 file format. See the Pervasive.SQL Advanced Operations Guide section for detailed information on how to use the Rebuild Utilities to convert your data files.
  • If you install Pervasive.SQL V8 over an existing version such as Pervasive.SQL 2000 or Btrieve 6.15, then those products will be archived when you install Pervasive.SQL V8 so that there are no component conflicts. You can use Pervasive System Analyzer later to restore the archived products if necessary. Your licenses from previous Pervasive products such as Btrieve 6.x and Pervasive.SQL 2000 will not be migrated to Pervasive.SQL V8.

Installation Tips

  • When installing Pervasive.SQL V8 for the first time on a system, Setup will check if all of the needed system files meet the minimum requirements. In some cases, these files are locked by the operating system and a reboot is required before Setup can continue. The following dialog box is displayed if this is the case.

Figure 5-1 Pervasive.SQL V8 Setup Reboot Required

Click Yes to reboot the system. Setup is then automatically be restarted.

Note
It is strongly recommended that you reboot your system if you encounter this message. If you do not reboot your system, Setup will encounter failures during engine and utilities configuration.

  • If you have any trouble with the following installation, see Chapter 12, Installation Troubleshooting.

Accessing README file information

It is highly recommended that you go through the README file to find out the latest changes and additions to Pervasive.SQL V8.

Prev
Upgrading Your Pervasive.SQL Installation 		Up
Check for Revisions 		Next
Upgrading to Pervasive.SQL Workgroup Engine from Earlier Pervasive.SQL Versions or Btrieve 6.x


Upgrading to Pervasive.SQL Workgroup Engine from Earlier Pervasive.SQL Versions or Btrieve 6.x

To upgrade to Pervasive.SQL V8 (Workgroup Edition) on a Windows machine

  1. Stop the Engine currently running

    If your Pervasive.SQL Workgroup engine is currently running, you must stop the engine and exit before you begin installation. To do this, right-click the engine icon in the task bar at the bottom of your screen and select the Stop Engines and Exit option.

  2. Launch the installation program from your Windows computer
    1. Insert the Pervasive.SQL V8 Workgroup for Windows CD in the CD-ROM drive of your Windows workstation.
    2. If the installation does not start automatically, click Start, select Run, and type drive:setup where drive is the drive letter of your CD-ROM device.

Note
Please see Installation Tips regarding the Pervasive.SQL V8 Setup Reboot Required dialog box.

The installation Welcome screen appears. Click Next to proceed with the installation.

  3. Certain programs and services on Windows can interfere with the Pervasive.SQL installation process. The Pervasive.SQL installation program detects these programs if they are running during your installation and informs you so that you can stop the programs. Doing so ensures that your installation completes successfully.

    Skip to Step 4 if you do not see a screen similar to Figure 5-2.

Figure 5-2 Detection of Programs Running During Installation

There are two categories of programs detected by the installation program:

  • Programs that must be stopped in order to install Pervasive.SQL.

    An example of a program in this category is one that utilizes the Pervasive.SQL Workgroup engine. If you are running such a program, Figure 5-3 displays if you try to continue without stopping the program.

Figure 5-3 Programs in Conflict with Installation

    • Programs that may cause issues with installation and should probably be stopped in order to ensure an issue-free installation.

      Examples of programs in this category include such products as Microsoft Internet Information Service (IIS) and others that can potentially lock system files.

      If you try to continue the installation without stopping the listed programs, Figure 5-4 displays and asks for confirmation to stop the conflict detection process. If you want the installation program to check for conflicts again, click Yes. If you want to continue the installation despite the possible conflict, click No.

Figure 5-4 Programs that May Conflict with Installation

  4. Read and accept the Software License Agreement

Figure 5-5 Pervasive Software's Software License Agreement

Read the Pervasive Software License Agreement. Click Yes to accept the terms of the agreement and continue installation.

  5. Select the Setup Type: Typical or Custom

Figure 5-6 Setup Type Dialog Box

Click Next to continue with installation.

Note About Typical Installation

The Typical installation, recommended for most users, takes default actions for most operations performed during the installation.

The Typical Workgroup installation installs the following components:

  • Pervasive.SQL V8 Engine, including the Transactional and Relational (ODBC) Interfaces
  • Utilities
  • Online documentation
  • Client requesters

No other components are needed or available.

Note About Custom Installation

The Custom installation is typically for advanced users; it lets you choose the components you want to install and specify the program folder name.

During a Custom installation you have the option to install the online documentation. The Transactional and Relational Workgroup Interfaces, Client Requesters and Utilities are always installed.

If you choose a custom install, skip now to Custom Installation Path .

  6. Select the workgroup installation directory

    The default installation location for Pervasive.SQL V8 is C:\PVSW (assuming the Windows system drive is C:\). You can specify a different location for the installation as shown in the following dialog box.

Figure 5-7 Select your Installation Directory

 Note
To select a different directory, enter the full path in the space provided, or click Browse to select an installation directory. If the folder you have chosen doesn't exist, you'll need to answer Yes to have setup create the folder for you.

Click Next to display your current installation settings.

  7. Verify your installation settings

Figure 5-8 Your Selected Installation Settings

If the displayed selections are correct, click Next to continue.

  8. Scan for previous Pervasive.SQL files.

    If you had a previous version of Pervasive.SQL on your system, Pervasive System Analyzer archives it before copying the updated Pervasive.SQL V8 files.

Figure 5-9 System Analysis Using PSA

  9. Pervasive.SQL V8 setup copies the files to the directory you have specified.

Figure 5-10 Setup Begins Copying Files

 Note
Only click Cancel if you want to stop installation and exit the Setup process.

  10. Your Pervasive.SQL V8 Workgroup upgrade is complete.

    The following dialog box informs you that the installation is complete.

Figure 5-11 Installation Complete Dialog Box

Click Finish.

  11. If installed files could not be copied because they were locked in memory, a reboot may be necessary at this point. Setup only prompts for a reboot if a locked file or some other event was detected that requires a reboot. Please reboot your system if prompted to do so in order to ensure proper operation of your Pervasive.SQL V8 product.

Figure 5-12 Installation Complete - Need Reboot

 Note
If you have any trouble with the installation, see Chapter 12, Installation Troubleshooting.

The install program modifies the PATH and CLASSPATH environment variables at the end of the installation process, if needed. These settings control how your Windows operating system finds Pervasive components. In Windows NT, these environment variables are stored in the Control Panel under the Environment tab on the System icon. In Windows 2000, these variables are stored in the Control Panel under the Advanced tab on the System icon.

Post Installation

  12. Register your product.

    After you have completed your Pervasive.SQL installation, you can register your product to receive news about future updates, and other timely information. You can also register later using a web, e-mail, or print-based registration form.

Figure 5-13 Product Registration Page

  13. Read the README and What's New.

Figure 5-14 View Readme and What's New

If you did not read the README file prior to installation as described in Before You Begin , please do so now from the registration page.

  14. Close the Registration page. Next the Pervasive System Analyzer (PSA) launches its tests of the transactional and relational interfaces. These tests ensure that your database engine is working as expected after installation.
  15. Test the Transactional Engine

    PSA now performs a series of tasks to ensure that the transactional engine is working properly.

Figure 5-15 Transactional Engine Test

In the space provided, specify the samples subdirectory of the installation location, as shown. Then click Next to run the tests and see the results.

  16. View the Transactional Test Results

    PSA displays a check mark for each test that passes and an X for each task that fails during the transaction engine test. A summary report is also provided in the information window, as shown in the following figure.

Figure 5-16 Transactional Engine Test Results from PSA

If any of the tests fail, see Chapter 12, Installation Troubleshooting.

Once your transactional engine tests are successful, click Next to test the relational engine.

  17. Test the Relational Engine

    PSA now performs a series of tasks to ensure that the relational engine is working properly.

Figure 5-17 Relational Engine Test

Enter the Machine Name and Engine DSN for the engine data you want to test. The default values are your current machine name and the sample demodata database. These values should be used unless you specifically wish to test a different database. Click Next to run the tests and see the results.

  18. View the Relational Test Results

    PSA displays a check mark for each test that passes and an X for each task that fails during the relational engine test. A summary report is also provided in the information window, as shown in the following figure.

Figure 5-18 Relational Engine Test Results from PSA

If any of the tests fail, see Chapter 12, Installation Troubleshooting.

Once your relational engine tests are successful, click Next.

  19. Your Pervasive.SQL V8 Workgroup upgrade and verification tests are complete.

    Thank you for choosing Pervasive.SQL.

What to do Next

Skip over the next section for custom installations and see Common Questions After Installing Pervasive.SQL .

Prev
Before You Begin 		Up
Check for Revisions 		Next
Custom Installation Path


Custom Installation Path

This section describes how to customize your installation of Pervasive.SQL V8.

  1. Choose the installation directory

    The default installation location for Pervasive.SQL V8 is C:\PVSW, assuming the Windows system drive is C:\. You can specify a different location for the installation as shown in the following dialog box.

Figure 5-19 Choosing Installation Directory of Pervasive.SQL V8

If you wish to change the default directory, click Browse and select the desired directory.

Click Next to proceed with the installation.

  2. Select components to install

    Pervasive.SQL V8 Workgroup edition currently contains only one optional component, which is online documentation.

Figure 5-20 Choose Components To Install

The Online Docs option is selected by default. If you choose not to install the online documentation, clear this check box. When you are finished, click Next.

  3. Choose the Program folder for menu items

    Specify the folder in which the Start Menu items will be placed. Pervasive installation suggests a name for the folder, which you can accept by clicking Next.

Figure 5-21 Choose your Program Folder

Click Next to accept the Program Folder name and display your current installation settings.

  4. Verify your installation settings

    Install now has enough information to start the installation process. A dialog box displays the list of options you have selected. If you want to change any of these selections, click Back.

    If the displayed selections are correct, click Next to continue.

Figure 5-22 Your Custom Installation Selections

The custom path rejoins the Typical installation path. See Step 8 .

Prev
Upgrading to Pervasive.SQL Workgroup Engine from Earlier Pervasive.SQL Versions or Btrieve 6.x 		Up
Check for Revisions 		Next
Common Questions After Installing Pervasive.SQL


Common Questions After Installing Pervasive.SQL

This section contains information that you should read after running the installation program. If you are having problems with your installation, go to Chapter 12, Installation Troubleshooting, or get help online from our Knowledge Base website at http://support.pervasive.com/eSupport.

The Workgroup engine must be installed on every computer that is expected to share data within your workgroup. Because every computer must have the Workgroup engine installed, there is no need to install the client software separately as there is for the Server engine.

How to Handle Data Source Names (DSNs)

The following table describes the procedures for upgrading your DSNs after you have installed the Pervasive.SQL upgrade.
Table 5-2 How to Proceed After Installing Workgroup
If your situation is like this . . . | . . . then you should do this next:
You have existing Pervasive.SQL 7 DSNs already defined. | You must delete and re-create all existing Pervasive.SQL 7 DSNs before you can access existing databases. Follow the instructions provided in Pervasive.SQL User's Guide Chapter 2, sections Deleting DSNs and Setting Up Database Access on Windows.
You have existing Pervasive.SQL 2000 DSNs already defined. | You should be able to access your databases by connecting to the existing DSNs. Follow the instructions provided in Pervasive.SQL User's Guide, Chapter 2, section Accessing Data via ODBC From Other Applications.
You do not have any Pervasive.SQL DSNs defined | You should be able to connect to the sample DEMODATA database now. Refer to Pervasive.SQL User's Guide for general information on working with Pervasive.SQL. Refer to Pervasive.SQL Advanced Operations Guide for detailed information on working with databases and database engines.

How Do I Convert My Files From Previous Pervasive Products?

Converting your data files to 8.x format is not required, but you must convert them if you wish to take advantage of new features offered by the Pervasive.SQL V8 engine.

Users of previous Btrieve versions: Use the Rebuild utility to convert your existing pre-6.0 or 6.x files to 7.x or 8.x format. For more information, refer to the Pervasive.SQL Advanced Operations Guide.

How Do I Read the Online Documentation?

Pervasive.SQL V8 documentation for Win32 platforms is in Microsoft HTML Help format. To read the documentation, select Start 4 Programs 4 Pervasive.SQL V8 4 Documentation 4 Pervasive.SQL V8 from the Windows Start menu.

You can also view the documentation in the form of Adobe Acrobat (PDF) files. These PDF files and an installation program for an Acrobat reader is available on the Pervasive.SQL V8 (Server Edition) CD-ROM.

There is also a README file on the distribution media that has the latest changes and additions to Pervasive.SQL V8.

What User License Was Installed with the Product?

The Pervasive.SQL V8 installation program automatically installs a five user permanent license when you install a Workgroup engine product.

There is no configuration necessary for the license. After installation, you can use the License Administrator utility to view your installed licenses. See the Pervasive.SQL User's Guide for more information on the License Administrator utility.

What Files Were Installed as Part of Pervasive.SQL V8?

Once installed, Pervasive.SQL V8 files reside in the following default directory structure.
\WINNT\SYSTEM32 (on WinNT/Win2000/WinXP systems) \WINDOWS\SYSTEM32 (on Win98 systems) |  | Microsoft system files Pervasive glue dlls
\Program Files\Common Files\Pervasive Software Shared
 | \PSA | Pervasive System Analyzer
 | \DOC | Online documentation
 | \PVSWCORE | Pervasive Services
\PVSW |  |
 | \BIN | Pervasive.SQL engines, requesters, and utilities
 | \DEMODATA | Contains sample database
 | \SAMPLES | Contains the sample database SAMPLE.BTR and UPPER.ALT, a sample Alternate Collating Sequence

Prev
Custom Installation Path 		Up
Check for Revisions 		Next
Customizing the Workgroup Engine


Customizing the Workgroup Engine

Prev
Common Questions After Installing Pervasive.SQL
Check for Revisions 		Next
Network Settings


Network Settings

How to Set up Your Workgroup Engine on Your Network and Understand the Default Settings

This chapter explains the default network settings for your database engine and how to customize them if your network requires different settings.

  • Determining What Kind of Network You Have
  • Default Engine Settings
  • Setting Up TCP/IP Support
  • Setting Up NetBIOS Support
  • SPX Protocol and the Workgroup Engine
  • Avoiding Unavailable Protocols
Prev
Customizing the Workgroup Engine
Check for Revisions 		Next
Determining What Kind of Network You Have


Determining What Kind of Network You Have

This section explains how to determine the network protocol that you should use with the database engine. If you already know what protocol or protocols are supported on your network, you can skip this section.

Database Engine on Windows

If your network is 100% Microsoft, and you have a Server engine, then your network probably uses TCP/IP. The Server engine does not support NetBIOS.

It is possible to run Btrieve applications over SPX on Microsoft networks, but ODBC applications over SPX require a NetWare server for name resolution. If you do not have a NetWare server on your network, you may not use SPX for ODBC applications.

If your network is 100% Microsoft, and you are using Workgroup engines, then you can use either NetBIOS or TCP/IP.

Prev
Network Settings 		Up
Check for Revisions 		Next
Default Engine Settings


Default Engine Settings

This section explains what server Configuration settings are related to networking support, and what the default values mean.

You can change these settings within PCC by double-clicking Configuration for the given database engine, then double-clicking Server, then Communication Protocols.

Auto Reconnect Timeout

Default: 180 seconds
If Pervasive AutoReconnect is enabled, this setting specifies how long the engine and client attempt to contact each other after a network interruption has occurred. By default, the client, server and multiple workgroup engines attempt to reconnect for three minutes before giving up. If the value of Enable Auto Reconnect is Off, then the Auto Reconnect Timeout value is ignored.

Enable Auto Reconnect

Default: Off
This setting determines whether the client, server or multiple workgroup engine attempts to reconnect to each other in the event of a network outage. If set to On, it allows the database connections to recover from intermittent or temporary network interruptions. If this value of this setting is Off, then the client returns a status code to the application immediately upon any failure to connect to the server, and the connection context is not preserved.

If you have this setting turned On, you can specify how long the client and database engine should attempt to reconnect by using the setting Auto Reconnect Timeout.

Listen IP Address

Default: 0.0.0.0
This setting specifies the IP address of the network interface card that the MicroKernel should listen on when the server computer has two network cards installed. This value is ignored if the server computer has only one network card, or if the value of TCP/IP Multihomed is On. This value is also ignored if TCP/IP is not in use by the database engine.

NetBIOS Port

Default: 66
This value specifies the port number the Workgroup engine listens on when using NetBIOS communications. The Server engine does not support NetBIOS, so this setting is ignored by the Server engine.

Note
This port setting must be the same for all Workgroup engines on the network. Workgroup engines with different port settings cannot communicate with one another.

Supported Protocols

Default: TCP/IP, NetBIOS
This setting specifies the vendor protocols that the database engine should attempt to use. When more than one protocol is specified, upon start up, the engine attempts to connect on all specified protocols. The protocol that connects first is then used for the remainder of the session.

You can often improve initial connection performance by removing the protocols that are not used on your network. For example, if you have a Server engine on an all-TCP/IP network, removing NetBIOS and SPX support may reduce the wait time during initial connections to the engine.

Note

The Server engine does not support the NetBIOS protocol.

The Workgroup engine does not support the SPX protocol.

TCP/IP Multihomed

Default: On
If your server computer has two network interface cards installed, you can use this setting to specify whether the server engine should listen on both network connections. If your computer has two network cards and this setting is turned off, you must use the setting Listen IP Address to specify which network card the server engine should use.

Prev
Determining What Kind of Network You Have 		Up
Check for Revisions 		Next
Setting Up TCP/IP Support


Setting Up TCP/IP Support

By default, TCP/IP is supported between Pervasive.SQL clients and remote engines or between multiple Workgroup engines. If you have modified the default settings or need to verify that TCP/IP support is available, refer to this section.

Note
In order to perform any of the tasks in this section, you must be seated at the console of the machine running the Workgroup engine. You cannot remotely configure the Workgroup engine.

Enabling TCP/IP Support

Follow this procedure to ensure that the database engine can communicate with clients over TCP/IP networks.

  1. From the Start menu, choose Programs 4 Pervasive.SQL V8 4 Control Center.
  2. In the PCC window, double-click on Pervasive.SQL Engines to display a list of the engines registered with PCC.
  3. Double-click on the icon representing your target engine. Double-click Configuration. Login if prompted. Double-click Server. Click on Communication Protocols. In the window to the right, double-click on Supported Protocols.
  4. A smaller dialog box appears, showing a list of Available protocols and a list of Selected protocols. If the list of Selected protocols includes the value Microsoft TCP/IP, then TCP/IP is already supported.

    If the list of Selected protocols does not include Microsoft TCP/IP, then you should click on this value in the left-hand window, and then click the > button to move it into the list of Selected protocols. Once the value appears in the right-hand window, click OK.

  5. Click [image] to apply the changes. You need to restart the engine for the changes to take effect.
  6. Remember that you also need to confirm that the client software on your other Workgroup computers are configured to use TCP/IP, as well. Please refer to Chapter 7, Client Network Configuration.

Enabling Multihomed TCP/IP Support

Follow this procedure when your Windows server computer has two network cards installed. By default, Pervasive.SQL assumes that you only have one network card installed.

  1. From the Start menu, choose Programs 4 Pervasive.SQL V8 4 Control Center.
  2. In the PCC window, double-click on Pervasive.SQL Engines to display a list of the engines registered with PCC.

    If the engine you want to configure is not listed, right-click on Pervasive.SQL Engines and choose Register New Engine.

  3. Double-click on the icon representing your target engine. Double-click Configuration. Login if prompted. Double-click Server. Click on Communication Protocols. In the window to the right, double-click on TCP/IP Multihomed.
  4. If you want the server engine to listen for client connections on both network cards, change the value to On. If you want the server engine to listen on only one card, change the value to Off. Click OK. If you only have one network card, this setting is ignored.
  5. If your server computer has two network cards, and you set the value of TCP/IP Multihomed to Off, you must double-click the setting Listen IP Address and specify the TCP/IP address of the card you want the database engine to listen to. If you do not specify an IP address, the database engine will not receive communications from either network card.
  6. Click [image] to apply the changes. You need to restart the server engine for the changes to take effect. You do not need to make any changes to client settings.
Prev
Default Engine Settings 		Up
Check for Revisions 		Next
Setting Up NetBIOS Support


Setting Up NetBIOS Support

By default, NetBIOS is supported among Pervasive.SQL Workgroup engines. If you have modified the default settings or need to verify that NetBIOS support is available, refer to this section.

Note
In order to perform any of the tasks in this section, you must be seated at the console of the machine running the Workgroup engine. You cannot remotely configure the Workgroup engine.

Enabling NetBIOS Support

Follow this procedure to ensure that the database engine can communicate with clients over NetBIOS networks.

  1. From the Start menu, choose Programs 4 Pervasive.SQL V8 4 Control Center.
  2. In the PCC window, double-click on Pervasive.SQL Engines to display a list of the engines registered with PCC.
  3. Double-click on the icon representing your target engine. Double-click Configuration. Login if prompted. Double-click Server. Click on Communication Protocols. In the window to the right, double-click on Supported Protocols.
  4. A smaller dialog box appears, showing a list of Available protocols and a list of Selected protocols. If the list of Selected protocols includes the value Microsoft NETBIOS, then NetBIOS is already supported.

    If the list of Selected protocols does not include Microsoft NETBIOS, then you should click on this value in the left-hand window, and then click the > button to move it into the list of Selected protocols. Once the value appears in the right-hand window, click OK.

  5. Click [image] to apply the changes. You need to restart the engine for the changes to take effect.
  6. Remember that you also need to confirm that the client software on your other Workgroup computers are configured to use NetBIOS, as well. Please refer to Chapter 7, Client Network Configuration.
Prev
Setting Up TCP/IP Support 		Up
Check for Revisions 		Next
SPX Protocol and the Workgroup Engine


SPX Protocol and the Workgroup Engine

The Pervasive.SQL Workgroup engine does not support SPX. You can use either TCP/IP or NetBIOS in conjunction with the Workgroup engine.

The Pervasive.SQL server engine supports SPX should you need to use this protocol in your environment.

Prev
Setting Up NetBIOS Support 		Up
Check for Revisions 		Next
Avoiding Unavailable Protocols


Avoiding Unavailable Protocols

It may be possible to improve performance on the initial connection to the database by disabling database communications support for any protocols that are not available on your network or that you do not wish to use.

Note
In order to perform any of the tasks in this section, you must be seated at the console of the machine running the Workgroup engine. You cannot remotely configure the Workgroup engine.

To Remove Network Protocol Support

Note
This procedure does not affect your operating system configuration in any way. This procedure only prevents the database communications system from attempting communications on unavailable or undesired protocols.

  1. From the Start menu, choose Programs 4 Pervasive.SQL V8 4 Control Center.
  2. In the PCC window, double-click on Pervasive.SQL Engines to display a list of the engines registered with PCC.
  3. Double-click on the icon representing your target server. Double-click Configuration. Login if prompted. Double-click Server. Click on Communication Protocols. In the window to the right, double-click on Supported Protocols.
  4. A smaller dialog box appears, showing a list of Available protocols and a list of Selected protocols. If the list of Selected protocols includes a value that is not supported on your network or that you do not wish to use, click on the value and then click the < button to move it into the list of Available Protocols. Repeat for any other protocols you do not wish to use. You must leave at least one protocol in the Selected protocols list.

    Once the given value(s) appear in the left-hand list, click OK.

  5. Click [image] to apply the changes. You need to restart the server engine for the changes to take effect.
  6. Remember that you also need to confirm that your client computers are configured to use the protocol remaining in the Selected protocols list. Please refer to Chapter 7, Client Network Configuration.
Prev
SPX Protocol and the Workgroup Engine 		Up
Check for Revisions 		Next
Client Network Configuration


Client Network Configuration

How to Configure the Network Settings for your Pervasive.SQL Clients

To access network files from a workstation using a Pervasive.SQL application, you must use the appropriate requester at that workstation. Your application's Pervasive.SQL calls go through the Requester, which sends them to the server for processing and then returns the reply to your application.

This chapter contains the following sections.

  • Default Settings
  • How to Configure the Pervasive Clients
  • Network Path Formats Supported by Pervasive Requesters
  • Using TCP/IP to Connect to a NetWare Server
  • Using SPX to Connect to a NetWare Server
  • Using TCP/IP to Connect to a Windows NT/2000 Server
  • Using SPX to Connect to a Windows NT/2000 Server
  • NetBIOS and the Pervasive.SQL Server Engine
  • Using TCP/IP to Connect to a Linux Server
  • Using the DOS Requesters
Prev
Avoiding Unavailable Protocols
Check for Revisions 		Next
Default Settings


Default Settings

This section lists the settings that are relevant to client networking.

TCP/IP is the default protocol for Pervasive.SQL. That is, TCP/IP is tried first if more than one protocol is set to be available.

Enable Auto Reconnect

Default: Off
This setting determines whether the client and server attempt to reconnect to each other in the event of a network outage. If set to On, it allows the database connections to recover from intermittent or temporary network interruptions. If this value of this setting is Off, then the client returns a status code to the application immediately upon any failure to connect to the server, and the connection context is not preserved.

If you have this setting turned On, you can specify how long the client and database engine should attempt to reconnect by using the setting Auto Reconnect Timeout in the Server configuration.

Note
This feature is not available on 16-bit clients.

Supported Protocols

Default: SPX, TCP/IP, NetBIOS
This setting specifies the vendor protocols that the database engine should attempt to use. When more than one protocol is specified, upon start up, the engine attempts to connect on all specified protocols. The protocol that connects first is then used for the remainder of the session.

You can often improve initial connection performance by removing the protocols that are not used on your network. For example, if you have a Server engine on an all-TCP/IP network, removing NetBIOS and SPX support may reduce the wait time during initial connections to the engine.

On the Linux platform, TCP/IP is the only supported protocol on the server.

Note
Server engines do not support the NetBIOS protocol. Workgroup engines do not support the SPX protocol.

TCP/IP Timeout for Communications Requester

Default: 15 seconds
This setting specifies the number of seconds the requester should wait for a TCP/IP connect request to succeed before timing out.

Prev
Client Network Configuration 		Up
Check for Revisions 		Next
How to Configure the Pervasive Clients


How to Configure the Pervasive Clients

This section contains information on configuring Pervasive client software.

  • Configuring the Win32 Requester
  • Configuring the Win16 Requester

Note
For information on configuring DOS requesters, see Using the DOS Requesters .

Configuring the Win32 Requester

The Win32 Requester serves as the Pervasive.SQL client for Windows 9X/ME and Windows NT/2000 workstations. You configure the Win32 Requester using the Configuration Utility within the Pervasive Control Center.

To Configure the Win32 Requester

  1. Click Start, point to Programs and select Pervasive.SQL V8.
  2. Select Control Center.
  3. Click Pervasive.SQL Engines and select the local machine.
  4. Select Configuration and then Client.
  5. Refer to the Advanced Operations Guide in section Configuration Reference for detailed information on the Configuration utility and settings.

Win32 Configuration Notes

WOW Application Users: The Win16 Requester provides thunking over to the Win32 Requester, which then handles your request as it does one from a Win32 application. To use these thunking capabilities, be sure to use the requesters included with the Pervasive.SQL package, and not those from an earlier version of Btrieve.

Configuring the Win16 Requester

The Win16 Requester is used in conjunction with Thunking in Windows 9X and Windows NT workstations.

Note
Clients using the 16-bit requesters will have only transactional access to the data files. No relational access will be available.

To Configure the Win16 Requester from Windows 9X/ME/NT/2000/XP:

  1. Click Start, point to Programs, then Pervasive.SQL V8, and select Control Center.
  2. Expand Pervasive.SQL servers and expand the desired server.
  3. Expand Configuration and expand Client-16 bit.
  4. Refer to the Advanced Operations Guide in section Configuration Reference for detailed information on the Configuration utility and settings.

Win16 Configuration Notes

To access a Windows NT server, your workstation must have the Microsoft Network Client for DOS and Windows loaded. You also need the NetWare SPX protocol stack. Pervasive Software recommends using the ODI drivers from Novell. You do not need to run NETX.EXE or be logged in to a NetWare server.

WOW Application Users: You must install both the Win16 Requester and the Win32 Requester. The Win16 Requester provides thunking over to the Win32 Requester, which then handles your request as it does one from a Win32 application. To use these thunking capabilities, be sure to use the requesters included with this package, and not those from an earlier version of Btrieve. Also, be sure to enable the Requester's Use Thunk option.

Prev
Default Settings 		Up
Check for Revisions 		Next
Network Path Formats Supported by Pervasive Requesters


Network Path Formats Supported by Pervasive Requesters

When using your Requester, you connect to the Pervasive server engine to access data files. This section shows the variations on network file syntax you can use to access files on your network using Btrieve or SQL applications.

Pervasive.SQL supports the Universal Naming Convention (UNC) and Drive path formats (explicit and current) across the majority of operating environments, including:
Table 7-1 Supported UNC and Drive Path Formats
Application Types | Environments | Network Client | Novell Login Types
Transactional | Windows (32-bit) | Microsoft | Bindery
Relational | Windows (16-bit) | Novell | NDS
 | DOS |  |

For more information on the path formats, see the sections that follow:

  • Universal Naming Convention (UNC) Path Formats
  • Drive-based Formats
  • NetWare Specific Formats
  • UNIX Path Formats

Universal Naming Convention (UNC) Path Formats

The following UNC path formats are supported on all clients to all servers:

\\ServerName\volume\path\file
\\ServerName\volume:[\]path\file

UNC syntax is resolved correctly regardless of the actual type of network operating system (NOS) that is operating on the target server.

Note
In all instances above, backslashes (\) can be interchanged with forward slashes (/) except for the double backslash (\\). The syntax [\] indicates that the backslash is optional.

Drive-based Formats

The following drive representations are supported on all clients to all servers:

Note
Do not map drive letters to the \\Tree\VolumeObject format found in Network Neighborhood. See NetWare Directory Services (NDS) Formats .

drive:file
drive:[\]path\file
file
[\]path\file
..\file

NetWare Specific Formats

NetWare path formats on all clients only to NetWare servers:

volume:[\]path\file (ServerName is derived from current drive)

NetWare Directory Services (NDS) Formats

Pervasive.SQL provides enhanced Novell Directory Service support over previous versions of Pervasive.SQL through complete integration with Novell's IntranetWare Client for Windows NT, and Windows 9X, and Microsoft's Service for Novell Directory Services for Windows 9X (MSNDS). These enhancements provide the following benefits to users and network administrators:

  • Better integration with NDS authentication capabilities when accessing the Pervasive.SQL Server Engine for NetWare.
  • Ability to resolve server names into network address by querying NDS instead of relying on the NetWare Bindery.
  • Support for NDS Volume and Directory Map objects in Btrieve file operations.

Note
Pervasive does not support the \\Tree\VolumeObject format found in Network Neighborhood. See NetWare Directory Services (NDS) Formats .

If you want to run 32-bit applications in an NDS environment, the Pervasive.SQL requesters work best with the Novell IntranetWare clients installed on the workstation. The following sections detail the level of support that Pervasive offers.

Support for Novell Clients for NetWare

Pervasive.SQL was tested with the following Novell clients:

  • IntranetWare Client for Windows NT v4.11
  • IntranetWare Client for Windows 9X v2.2
  • IntranetWare Client for DOS/Windows 3.x v2.2

Each of these clients provide the set of NDS specific APIs needed by the Pervasive.SQL requesters to integrate fully with the NDS environment. All Pervasive.SQL requesters will detect these clients' presence automatically; no additional Pervasive.SQL configuration changes are required. When these clients are available to the Pervasive.SQL requesters, the following operations are supported:

  • Network login via NDS (bindery context does not need to be set on the target server)
  • NetWare server address resolution for SPX addresses
  • Drive letters mapped to NDS Volume Objects through either the Map utility or Network Neighborhood may be used to specify Btrieve file names or SRDE dictionary and data directories
  • NDS Volume Objects and Directory Map Objects may be used to specify Btrieve file names with Win32, and Win16 applications

The file name and path formats supported by the Pervasive.SQL requesters through the Novell clients are listed in the table below:
Table 7-2 File name and Path formats for Novell Clients for NetWare
Format | Btrieve Apps | Notes | SQL Apps
<drive letter>:[\]path\file | ü | (1) | ü
\\server\volume\path\file | ü |  | ü
\\server\volume:[\]path\file | ü |  | ü
server\volume:[\]path\file | ü |  | ü
volume:[\]path\file | ü | (4) | ü
VolumeObject:[\]path\file | ü | (2) (3) | û
\\VolumeObject\path\file | ü | (2) (3) | û
DirectoryMap:[\]path\file | ü | (2) (3) | û
\\DirectoryMap\path\file | ü | (2) (3) | û
\\Tree\VolumeObject\path\file | û |  | û
\\Tree\DirectoryMap\path\file | û |  | û

1 <drive letter> can be redirected to a server\volume:, or NDS Volume or Directory Map object.
2 Not supported by the Btrieve DOS requester.
3 See Novell documentation for rules about specifying NDS context when using NDS objects.
4 Requires that the current drive is mapped to the target NetWare server.

Support for Microsoft Clients for NetWare

Pervasive.SQL was tested with the following Microsoft clients for NetWare:

  • Microsoft Service for Novell Directory Services (Windows 9X)
  • Microsoft Client Service for NetWare (Windows NT/2000). This client limits your NDS support; Pervasive recommends using the Novell IntranetWare client.
  • Microsoft Client Service for NetWare (Windows 9X)

Note
The Win16 Requesters require the Novell components NWCALLS.DLL and NWNET.DLL. Win32 Requesters using the Microsoft Service for NDS also require these files.

The file name and path formats supported by the Pervasive.SQL requesters using Microsoft's clients for NetWare on Windows 9X/ME and Windows NT/2000 are listed in the following table.
Table 7-3 File name and Path formats for Microsoft Clients for NetWare
Format | Btrieve Apps Win16 Win32 |  | Notes | SQL Apps
<drive letter>:[\]path\file | ü | ü | (1) | ü
\\server\volume\path\file | ü | ü |  | ü
\\server\volume:[\]path\file | ü | ü |  | ü
server\volume:[\]path\file | ü | ü |  | ü
volume:[\]path\file | ü | ü | (4) | ü
VolumeObject:[\]path\file | ü | û | (2) (3) (5) | û
\\VolumeObject\path\file | ü | û | (2) (3) (5) | û
DirectoryMap:[\]path\file | ü | û | (2) (3) (5) | û
\\DirectoryMap\path\file | ü | û | (2) (3) (5) | û
\\Tree\VolumeObject\path\file | û | û |  | û
\\Tree\DirectoryMap\path\file | û | û |  | û

1 <drive letter> can be redirected to a server\volume:, or NDS Volume or Directory Map object on Windows 95 with MSNDS. On Windows NT 4.0 with CSNW, <drive letter> can only be redirected to a server\volume: name; using Network Neighborhood to map a <drive letter> to an NDS object is not supported for Win32 applications.
2 Not supported by the Btrieve DOS requester.
3 Supported for applications using the Win16 Pervasive requesters only (with no thunking to 32-bit).
4 Requires that the current drive is mapped to the target NetWare server.
5 See Novell documentation for rules about specifying NDS context when using NDS objects.

Implementation Notes for the Microsoft NetWare Clients

The Microsoft Service for Novell Directory Services (MSNDS) allows Windows 9X workstations to login to NDS trees and redirect drive letters to NDS servers. MSNDS also supports Windows 16-bit 'NDS-aware' applications by supporting the Novell Windows 16-bit client DLLs, NWCALLS.DLL and NWNET.DLL. MSNDS does not provide 32-bit API support for NDS-aware applications. Windows 9X, however, does provide a thunk mechanism allowing 32-bit applications to call 16-bit applications. The Pervasive.SQL requesters take advantage of that mechanism to provide NDS support, although currently the 32-bit requesters do not allow NDS object names to be used in UNC-style paths as they do with the Novell clients. On Windows 9X workstations with MSNDS installed, the Pervasive.SQL requesters support the following NDS operations:

  • Network login via NDS (bindery context does not need to be set on the target server)
  • NetWare server address resolution for SPX addresses
  • Drive letters mapped to NDS Volume Objects or Directory Map Objects through either the Map utility or Network Neighborhood may be used to specify Btrieve file names, or SRDE dictionary and data directories when logging into a Pervasive.SQL database, only with WIN16 applications
  • NDS Volume Objects and Directory Map Objects may be used to specify Btrieve file names, only with Win16 applications

Like MSNDS, the Microsoft Client Service for NetWare (CSNW) on Windows NT 4.0 allows Windows NT 4.0 workstations to log in to NDS trees and redirect drive letters to NDS servers, as well as supporting Windows 16-bit 'NDS-aware' applications by supporting the Novell Windows 16-bit client DLLs. CSNW does not provide 32-bit API support for NDS-aware applications.

Unlike Windows 95, Windows NT does not provide a thunk mechanism allowing 32-bit applications to initiate calls to 16-bit applications (it does allow 16-bit applications to call 32-bit applications, which the Pervasive requesters support). The lack of support for 32-bit 'NDS-aware' applications coupled with the lack of a thunk mechanism for 32-bit to 16-bit calling conventions significantly reduces the ability of the Pervasive.SQL requesters to support NDS environments. On Windows NT 4.0 workstations with CSNW installed, Pervasive.SQL supports the following NDS operations:

  • Network login via NDS for DOS applications and Win16 applications that do not thunk to the Win32 requester (bindery context does not need to be set on the target server)
  • Network login via NDS for Win32 applications, when accessing the Pervasive.SQL for NetWare server engine using SPX as the transport
  • NetWare server address resolution for SPX addresses
  • NDS Volume Objects and Directory Map Objects may be used to specify Btrieve file names for Win16 applications that do not thunk to the Win32 requester

UNIX Path Formats

Incoming paths on a Linux server using Samba will be processed as follows in order of relative priority:

Share names

\\<server>\<sharename>\<path>

The smb.conf file must be configured to accept <sharename>, otherwise it will default to the following:

Absolute paths

\\<server>\<absolute_path>

If the smb.conf file is not configured properly or not found on the target server, the absolute path is used.

For more information on the Linux version of Pervasive.SQL V8, see the "Linux Supplementary Documentation" section of Pervasive.SQL User's Guide.

Prev
How to Configure the Pervasive Clients 		Up
Check for Revisions 		Next
Using TCP/IP to Connect to a NetWare Server


Using TCP/IP to Connect to a NetWare Server

This section documents the use of TCP/IP when connecting to a Pervasive.SQL server running on a NetWare machine.

Configuring Pervasive.SQL to use TCP/IP

TCP/IP is the default protocol when connecting to NetWare servers, meaning that if both TCP/IP and SPX protocols are available, TCP/IP is the first one the Communications Requester attempts to use.

If you have a working TCP/IP setup from your client to your NetWare server, you should not have to do anything in addition to make Pervasive.SQL work with TCP/IP and NetWare.

Configuring a Client For the Server IP Address

When Pervasive.SQL operates in a TCP/IP network, your client must be able to obtain the name of your NetWare server from the IP address given to that server by your network administrator. There are two mechanisms that enable this address to name translation:

  • DNS (Domain naming service)
  • Editing the Hosts file (a method typically used in small to medium sized networks)

The following procedures show how to set up the IP address using each method.

Using DNS to Configure the Server IP Address

When you use DNS, you specify settings that allow your computer to look up the name of the server in a database of addresses. Your network administrator can provide the information you need to configure DNS.

To configure your clients to use DNS to resolve the server IP address:

For Windows 9X/NT clients:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click Network,
  3. select Protocols, select TCP/IP and click Properties.
  4. Click the DNS tab.
  5. Enable DNS and enter the appropriate server information from your network administrator.

For Windows 2000 clients:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click Network and Dial-up Connections, select Local Area Connection and click Properties.
  3. From the component list, select TCP/IP and click Properties.
  4. Enable DNS and enter the appropriate server information from your network administrator.
Using the Hosts File to Configure the Server IP Address

The Hosts file is a way to manually enter a relationship between a name and an IP address. Use this method if DNS is not used in your organization.

To Edit the Hosts file on your Windows client

  1. Find your Hosts file as follows on your Windows machine.

    For Windows NT/2000:
    \WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

    For Windows 9X/ME:
    \WINDOWS\SYSTEM\DRIVERS\ETC\HOSTS

  2. Edit the Hosts file with a text editor such as Notepad.
  3. Enter your server's IP address and name in the hosts file as a new line as shown in the following example. Your network administrator can provide you with the IP address of your server.

    # the following is an example of a Hosts file entry

    146.23.45.2 acctserver

Prev
Network Path Formats Supported by Pervasive Requesters 		Up
Check for Revisions 		Next
Using SPX to Connect to a NetWare Server


Using SPX to Connect to a NetWare Server

This section documents the use of SPX when connecting to a Pervasive.SQL server running on a NetWare machine.

Configuring Pervasive.SQL V8 to use SPX

SPX is a native protocol to NetWare. There should be no special requirements for operating Pervasive.SQL with SPX on NetWare. However, note the following:

SPX is not the default protocol for Pervasive.SQL. Consequently, if you have both TCP/IP and SPX installed, Pervasive.SQL attempts to use TCP/IP first. If you want SPX to be used, follow these steps:

To Configure your Clients to use SPX with NetWare Servers if Both TCP/IP and SPX are Installed:

  1. Click Start, point to Programs and select Pervasive.SQL V8.
  2. Select Control Center.
  3. Expand Pervasive.SQL Engines and expand the desired engine.
  4. Expand Configuration and expand Client.
  5. Select the Communication protocols and, in the right-hand pane, right-click on Supported protocols.
  6. Highlight Microsoft TCP/IP from the list of selected protocols and click the < button to move it off the selected list.
  7. Click OK.

To use SPX with NetWare, also ensure that your network packet size is appropriate for your network. By default the Receive Packet Size option of the Configuration utility (detailed in the Advanced Operations Guide) is set to 1500, which is the correct value for Ethernet networks. If, however, you have a Token-ring network, use the Configuration utility to modify your Receive Packet Size to 4096.

Using Either Microsoft or Novell's SPX when Connecting to NetWare Servers

If you select Novell SPX using the Supported Protocols setting in the Configuration utility, this means that all Pervasive SPX calls will be made through the Novell component NWIPXSPX.DLL. Both Novell and Microsoft support this DLL, so you could be using Microsoft SPX even though the Pervasive setting shows that you are using Novell SPX.

To determine which version of SPX (Microsoft or Novell) you are using from your Windows workstation:

In Windows NT:

  • Click Start, point to Settings and select Control Panel. Double-click Network, and look for IPX/SPX in the list. If the entry says "IPX/SPX compatible-protocol", you have Microsoft's SPX installed. Otherwise, you are using Novell's IPX/SPX protocol.

In Windows 2000:

  • Click Start, point to Settings and select Control Panel. Double-click Network and Dial-up Connections, select Local Area Connection and click Properties. Look for IPX/SPX in the list. If the entry says "IPX/SPX compatible-protocol", you have Microsoft's SPX installed. Otherwise, you are using Novell's IPX/SPX protocol.

Pervasive.SQL supports both the Microsoft and Novell versions of SPX. If you do not use the Novell Client 32 to communicate with the NetWare server, you could encounter a Status Code 3119 when you first attempt a connection to the NetWare server. Subsequent connections should clear that condition.

Changing the Default Server Listening Port (Advanced)

Most users should never have to use this procedure. This procedure should only be performed by a system administrator.

In normal TCP/IP operation, clients use a particular port number to communicate with servers. Pervasive.SQL by default listens on port 1583. For TCP/IP to function properly, all clients and all servers must use the same port.

Pervasive recommends that you do not modify the server listening port unless you have a conflict with port number of 1583. If you do have a conflict, you can override the Pervasive Database port settings with an entry in the SERVICES file for each machine. The SERVICES file is located at:

SYS:\ETC\SERVICES

For example, if you wanted to change the listening port to 80 for Pervasive.SQL, you would add the following entry in your SERVICES file:

psql 80/tcp

After changing your server listening port, you must stop and restart your Pervasive.SQL services for the changes to take effect. See "Using Pervasive.SQL" in Pervasive.SQL User's Guide.

Note
Entries in the NetWare SERVICES file are NOT case-sensitive.

Prev
Using TCP/IP to Connect to a NetWare Server 		Up
Check for Revisions 		Next
Using TCP/IP to Connect to a Windows NT/2000 Server


Using TCP/IP to Connect to a Windows NT/2000 Server

This section documents the use of TCP/IP when connecting to a Pervasive.SQL server running on a Windows NT/2000 machine.

Tasks

Configuring a Client for the Server IP Address

When Pervasive.SQL operates in a TCP/IP network, your client must be able to obtain the name of your Windows server from the IP address given to that server by your network administrator. There are two mechanisms that enable this address to name translation:

  • DNS (Domain naming service)
  • Editing the Hosts file (a method typically used in small to medium sized networks)

The following procedures show how to set up the IP address using each method.

Using DNS to Configure the Server IP Address

When you use DNS, you specify settings that allow your computer to look up the name of the server in a database of addresses. Your network administrator can provide the information you need to configure DNS.

To configure your clients to use DNS to resolve the server IP address:

For Windows 9X/NT clients:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click Network,
  3. select Protocols, select TCP/IP and click Properties.
  4. Click the DNS tab.
  5. Enable DNS and enter the appropriate server information from your network administrator.

For Windows 2000 clients:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click Network and Dial-up Connections, select Local Area Connection and click Properties.
  3. From the component list, select TCP/IP and click Properties.
  4. Enable DNS and enter the appropriate server information from your network administrator.
Using the Hosts File to Configure the Server IP Address

The Hosts file is a way to manually enter a relationship between a name and an IP address. Use this method if DNS is not used in your organization.

To Edit the Hosts file on your Windows client

  1. Find your Hosts file as follows on your Windows machine.

    For Windows NT/2000:
    \WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

    For Windows 9X/ME:
    \WINDOWS\SYSTEM\DRIVERS\ETC\HOSTS

  2. Edit the Hosts file with a text editor such as Notepad.
  3. Enter your server's IP address and name in the hosts file as a new line as shown in the following example. Your network administrator can provide you with the IP address of your server.

    # the following is an example of a Hosts file entry

    146.23.45.2 acctserver

Preventing the Windows Dial-Up Network Dialog Box from Displaying When Using a Pervasive Application with TCP/IP

The Windows Dial-Up Networking dialog box can display when a TCP/IP request is made to Windows. Usually, this is to make an Internet connection, but this feature can be an annoyance when using Pervasive applications and TCP/IP.

To Prevent the Dial-Up Networking Dialog Box from Displaying Automatically:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click the Internet icon in Control Panel.
  3. Click the Connection tab.
  4. Clear the check box titled Connect to the Internet As Needed. In Windows 2000, this button is titled Dial whenever a network connection is not present.

Note
While this stops the dialog box from displaying with Pervasive applications, this also has the side effect that other applications such as Internet browsers will no longer automatically spawn the Dial-Up Networking dialog box when a connection to the Internet is needed. In that case, you need to connect to the Internet manually using Dial-Up Networking.

According to Microsoft, the Connect to the Internet As Needed check box is designed to launch Dial-Up Networking whenever TCP/IP is used by an application, so this behavior is correct.

Changing the Default Server Listening Port (Advanced)

Most users should never have to use this procedure. This procedure should only be performed by a system administrator.

In normal TCP/IP operation, clients use a particular port number to communicate with servers. By default, Pervasive.SQL listens on port 1583. For TCP/IP to function properly, all clients and all servers must use the same port numbers.

Pervasive recommends that you do not modify the server listening port unless you have a conflict. If you do have a conflict, you can override the Pervasive.SQL port settings with an entry in the SERVICES file for each machine, client and server. The SERVICES file is located at:
Windows NT/2000

\WINNT\SYSTEM32\DRIVERS\ETC\SERVICES
Windows 9X

\WINDOWS\SERVICES

For example, if you wanted to change the listening port to 80 for Pervasive.SQL, you would add the following entry in your SERVICES file:

psql 80/tcp

Note
Entries in the Windows NT SERVICES file are case-sensitive.

After changing your server listening port, you must stop and restart your Pervasive.SQL services for the changes to take effect. See the section "Using Pervasive.SQL" in Pervasive.SQL User's Guide.

Prev
Using SPX to Connect to a NetWare Server 		Up
Check for Revisions 		Next
Using SPX to Connect to a Windows NT/2000 Server


Using SPX to Connect to a Windows NT/2000 Server

This section documents the use of SPX when connecting to a Pervasive.SQL server running on a Windows NT/2000 machine.

Note
You cannot use SPX in conjunction with a Workgroup engine.

Name Resolution

If you are using Btrieve applications only, then you can use SPX in an all-Windows environment. If you have an ODBC application, however, Pervasive.SQL depends on NetWare for name resolution. You will need at least one NetWare server to perform name resolution for your ODBC applications.

Tasks

Configuring Pervasive.SQL to use IPX/SPX

IPX/SPX is not a native protocol on the Windows NT/2000 platforms. If you want to use IPX/SPX, perform all of the following procedures to ensure proper operation with Pervasive.SQL.

Changing Pervasive's configuration to use IPX/SPX with Windows NT/2000:

If you have both TCP/IP and IPX/SPX Installed in the Network Icon of the Control Panel, you must remove
TCP/IP from the client configuration to make IPX/SPX function with Pervasive applications:

  1. Click Start, point to Programs and select Pervasive.SQL V8.
  2. Select Control Center.
  3. Expand Pervasive.SQL Engines and expand the desired engine.
  4. Expand Configuration and expand Client.
  5. Select the Communication protocols and, in the right-hand pane, right-click on Supported protocols.
  6. Highlight Microsoft TCP/IP from the list of selected protocols and click the < button to move it off the selected list.
  7. Click OK.
Changing Windows Configuration to Make IPX/SPX Run with Pervasive.SQL:

Ensure that your IPX/SPX settings are correct

In the Windows NT Control Panel:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click on the Network icon.
  3. Select IPX/SPX Compatible Transport and click Properties.
  4. Click the Advanced tab.
  5. Under Frame Type setting, ensure that the correct frame type for your network is selected. Do not use Auto Frame Type Detection.
  6. Still under the Advanced tab, click Network Address.
  7. Enter a non-zero value for your network address. For information about what your network address should be, contact your system administrator.

In the Windows 2000 Control Panel:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click on the Network and Dial-up Connections icon.
  3. Select Local Area Connection and click Properties.
  4. Scroll down to IPX/SPX/NetBIOS Compatible Transport, highlight and click the Properties button.
  5. In the Frame Type field, ensure that the correct frame type for your network is selected. Do not use Auto Detect.
  6. In the Network number field, enter a non-zero value for your network address. For information about what your network address should be, contact your system administrator.

Ensure that your IPX/SPX Maximum Packet size (MaxPktSize) is set correctly in the Windows NT/2000 registry:

  1. Click Start and select Run.
  2. Type regedit and press Enter.
  3. Find the registry entry using the following paths:
    Windows NT: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NwlnkIPX\NetConfig\driver_name\MaxPktSize.
    Windows 2000: HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NwlnkIPX\Parameters\Adapters\name\MaxPktSize.
  4. Ensure that the MaxPktSize setting in the Windows registry is set to 576 decimal or 240h.
Prev
Using TCP/IP to Connect to a Windows NT/2000 Server 		Up
Check for Revisions 		Next
NetBIOS and the Pervasive.SQL Server Engine


NetBIOS and the Pervasive.SQL Server Engine

Pervasive.SQL Server engine does not support NetBIOS. Only the Workgroup engine supports NetBIOS.

Prev
Using SPX to Connect to a Windows NT/2000 Server 		Up
Check for Revisions 		Next
Using TCP/IP to Connect to a Linux Server


Using TCP/IP to Connect to a Linux Server

Your Samba must be properly configured on your Linux server to properly network with Windows-based clients. See Chapter 13, Network Settings for Linux in Getting Started With Pervasive.SQL (Server edition) for more information.

Tasks

Configuring a Client for the Server's IP Address

When Pervasive.SQL operates in a TCP/IP network, your client must be able to obtain the name of your Linux server from the IP address given to that server by your network administrator. There are two mechanisms that enable this address to name translation:

  • DNS (Domain naming service)
  • Editing the Hosts file (a method typically used in small to medium sized networks)

The following procedures show how to set up the IP address using each method.

Using DNS to Configure the Server IP Address

When you use DNS, you specify settings that allow your computer to look up the name of the server in a database of addresses. Your network administrator can provide the information you need to configure DNS.

To configure your clients to use DNS to resolve the server IP address:

For Windows 9X/NT clients:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click Network,
  3. select Protocols, select TCP/IP and click Properties.
  4. Click the DNS tab.
  5. Enable DNS and enter the appropriate server information from your network administrator.

For Windows 2000 clients:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click Network and Dial-up Connections, select Local Area Connection and click Properties.
  3. From the component list, select TCP/IP and click Properties.
  4. Enable DNS and enter the appropriate server information from your network administrator.
Using the Hosts File to Configure the Server IP Address

The Hosts file is a way to manually enter a relationship between a name and an IP address. Use this method if DNS is not used in your organization.

To Edit the Hosts file on your Windows client

  1. Find your Hosts file as follows on your Windows machine.

    For Windows NT/2000:
    \WINNT\SYSTEM32\DRIVERS\ETC\HOSTS

    For Windows 9X/ME:
    \WINDOWS\SYSTEM\DRIVERS\ETC\HOSTS

  2. Edit the Hosts file with a text editor such as Notepad.
  3. Enter your server's IP address and name in the hosts file as a new line as shown in the following example. Your network administrator can provide you with the IP address of your server.

    # the following is an example of a Hosts file entry

    146.23.45.2 acctserver

Preventing the Windows Dial-Up Network Dialog Box from Displaying When Using a Pervasive Application with TCP/IP

The Windows Dial-Up Networking dialog box can display when a TCP/IP request is made to Windows. Usually, this is to make an Internet connection, but this feature can be an annoyance when using Pervasive applications and TCP/IP.

To Prevent the Dial-Up Networking Dialog Box from Displaying Automatically:

  1. Click Start, point to Settings and select Control Panel.
  2. Double-click the Internet icon in Control Panel.
  3. Click the Connection tab.
  4. Clear the check box titled Connect to the Internet As Needed. In Windows 2000, this button is titled Dial whenever a network connection is not present.

Note
While this stops the dialog box from displaying with Pervasive applications, this also has the side effect that other applications such as Internet browsers will no longer automatically spawn the Dial-Up Networking dialog box when a connection to the Internet is needed. In that case, you need to connect to the Internet manually using Dial-Up Networking.

According to Microsoft, the Connect to the Internet As Needed check box is designed to launch Dial-Up Networking whenever TCP/IP is used by an application, so this behavior is correct.

Prev
NetBIOS and the Pervasive.SQL Server Engine 		Up
Check for Revisions 		Next
Using the DOS Requesters


Using the DOS Requesters

See Chapter 9, Using the DOS Requesters.

Prev
Using TCP/IP to Connect to a Linux Server 		Up
Check for Revisions 		Next
Application Configuration Scenarios


Application Configuration Scenarios

Common Scenarios for Setting up Your Database Engine

This chapter explains how to configure your database engine for several common application scenarios.

  • Support for Active Directory Service
  • Using Multiple Applications
  • Using a Server Engine and a Workgroup Engine Concurrently
  • Accessing Data on Other Computers
Prev
Using the DOS Requesters
Check for Revisions 		Next
Support for Active Directory Service


Support for Active Directory Service

This section describes how to install and configure Pervasive.SQL in an environment that uses Microsoft Active Directory service.

What Is Active Directory?

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

The Microsoft Web site provides much information about Active Directory. The following Web links provide information to help you learn about Active Directory.

  • Home page for Active Directory — http://www.microsoft.com/windows2000/technologies/directory/ad/default.asp
  • Overview of Active Directory — http://www.microsoft.com/windows2000/server/evaluation/features/dirlist.asp
  • Overview of Active Directory Service — http://www.microsoft.com/windows2000/server/evaluation/business/addatasheet.asp

Installation of Active Directory

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

Microsoft provides step-by-step guides to help you install and configure Active Directory service. The following Web links provide information to help you install and manage Active Directory.

  • Windows 2000 Step-by-Step Guides — http://www.microsoft.com/windows2000/techinfo/planning/walkthroughs/default.asp
  • Installing a Windows 2000 Server as a Domain Controller — http://www.microsoft.com/windows2000/techinfo/planning/server/serversteps.asp
  • Managing Active Directory — http://www.microsoft.com/windows2000/techinfo/planning/activedirectory/manadsteps.asp

Note that Windows 2000 implements TCP/IP as the default protocol and relies on TCP/IP for most of the services associated with the operating system, including Active Directory service. Integration of Active Directory with NetWare Directory Services is possible with Microsoft Directory Synchronization Services (MSDSS) and DirSync. For more information, refer to the Microsoft Web site: http://www.microsoft.com/WINDOWS2000/sfn/msdss.asp.

Installation of Pervasive.SQL

The installation of the Pervasive.SQL database engine in an Active Directory environment requires no special steps. Install it as described in Installing the Pervasive.SQL Workgroup Engine .

The following environment modes are supported:

  • Native mode — all domain controllers run Windows 2000
  • Mixed mode — some domain controllers run Windows 2000

You may install the Pervasive.SQL database engine on a domain controller if you choose. Be aware, however, that activity on the domain controller may affect the performance of the database engine. For this reason, you may prefer to install Pervasive.SQL on a server that is not a domain controller.

Server and Client Support

Pervasive.SQL Workgroup runs on Windows 2000 Server and Windows NT Server (version 4) within an Active Directory environment. The Pervasive.SQL clients run on all Windows 32-bit platforms within an Active Directory environment.

The DOS TCP/IP requester (BREQTCP) is supported within an Active Directory environment. The DOS SPX requester (BREQUEST or BREQNT) is not supported because it requires the SPX protocol.

Directory and File Permissions

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 Pervasive.SQL table file, you will be unable to write to the table.

Microsoft Terminal Services Support

Pervasive.SQL Workgroup is supported for use with Microsoft Terminal Server and Citrix MetaFrame running within an Active Directory environment. For more information about Terminal Services and Citrix MetaFrame, see Pervasive.SQL and Terminal Services .

Pervasive Administrative Authority

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 Pervasive administrative privileges.

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

  • Log on locally
  • Administrator privileges or belong to the Pervasive_Admin group

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

You may 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 Pervasive.SQL 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.

Active Directory Tasks

This section explains the tasks needed to ensure users have Pervasive administrative privileges. The tasks assume the following:

  • Network user IDs have been added for users who need Pervasive administrative privileges
  • A Pervasive_Admin group has been created on the domain controller and users added to the group
  • Windows 2000 Server is the operating system on the domain controller.

To Create the Pervasive_Admin Group on a Domain Controller

  1. Click Start 4 Programs 4 Administrative Tool 4 Active Directory Users and Computers.
  2. Expand the tree for the domain to which you want to add the Pervasive_Admin group (click the plus sign).

    For example, the following image shows the expanded tree for the ADSTEST.com domain.

  3. Right-click on the Organizational Unit or folder that you are using in your Active Directory environment to house groups, then click New 4 Group. For example, the following image shows an Organizational Unit named "Groups," but your Organizational Unit may be named differently.

 Note
If your Active Directory environment does not have an Organizational Unit to house groups, you need to create one. Click on the domain root (for example, in the figure above, you would right-click on ADSTEST.com), then click Action 4 New 4 Organizational Unit. Type a meaningful name for the unit, then click OK.

  4. For Group name, type Pervasive_Admin. Click Domain local for group scope.

 Note
The Pervasive_Admin group must have a scope of Domain local. Do not use Global or Universal.

  5. Click OK.

    Now that the Pervasive_Admin group exists, you need to add users to it.

  6. On the Active Directory Users and Computers window, right-click on the Pervasive_Admin group, then click Properties. (You may also double-click the group.)
  7. Click the Members tab on the properties dialog.
  8. Click Add on the Members tab.
  9. Click on the user in the Name list that you want to add to the Pervasive_Admin group, then click Add.

    The user is added to the list on the bottom. For example, the following image shows that user ADS_USER1 has been added.

  10. Click OK.

    The user you added now appears as a member of the Pervasive_Admin group.

  11. Click OK to exit the properties dialog.
  12. Add the Pervasive_Admin group to the Log on locally privileges (complete the task To Grant Log On Locally Privileges to the Pervasive_Admin Group).

To Grant Log On Locally Privileges to the Pervasive_Admin Group

  1. Click Start 4 Settings 4 Control Panel.
  2. Double-click Administrative Tools (or right-click then click Open) to open the Administrative Tools window.
  3. Double-click Domain Controller Security Policy (or right-click then click Open) to open the Domain Controller Security Policy window.

 Note
Ensure that you open Domain Controller Security Policy and not Domain Security Policy.

  4. Expand the following security settings (click the plus signs):
    • Security Settings
    • Local Policies
  5. Click User Rights Assignment.
  6. Scroll the policies in the right pane until you locate Log on locally.
  7. Double-click the Log on locally policy (or right-click the policy then click Security).

    The policy setting dialog appears.

  8. Click Add.

    The dialog appears on which you add users and groups.

  9. Type Pervasive_Admin in the Users and group names field.

    You may also specify the group by clicking Browse and navigating to the group through dialogs.

  10. Click OK.

    The Security Policy Setting dialog appears with Pervasive_Admin added.

  11. Click OK to exit the Security Policy Setting dialog.
  12. Exit the Domain Controller Security Policy window.

Prev
Application Configuration Scenarios 		Up
Check for Revisions 		Next
Using Multiple Applications


Using Multiple Applications

Sometimes, two or more 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.
If the applications run concurrently (that is, if two or more applications are using the database engine at the same time) ...
You should configure the engine by adding together all the recommended values for each parameter. For example, if one application vendor suggests Performance Tuning | Number of Input/Output Threads should be set to 4, and another application vendor suggests this parameter should be set to 8, then you should set it to 12.
If the default value is higher than the sum of the recommended settings, then do not change the default value.
Do not add up the recommended values for any buffer size settings, or log file size settings. Use the largest recommended setting. Again, do not change the default if it is larger than any vendor recommendation.
If the applications do not run concurrently (that is, if only one application is running at any given point in time) ...
You should configure the engine by using the largest recommended value for each parameter. For example, if one application vendor suggests Performance Tuning | Number of Input/Output Threads should be set to 4, and another application vendor suggests this parameter should be set to 8, then you should set it to 8.
If the default value is higher than the largest recommended setting, then do not change the default value.

Settings Affected by Multiple Applications

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.

Compatibility | Create File Version

Some applications may require that new files be created with version 6.x or 7.x file format, while other applications may require version 8.x file format (the default).

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 the Distributed Tuning Objects.

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

Data Integrity | Transaction Durability

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.

Prev
Support for Active Directory Service 		Up
Check for Revisions 		Next
Using a Server Engine and a Workgroup Engine Concurrently


Using a Server Engine and a Workgroup Engine Concurrently

You can use your Workgroup engine to access files on a remote file server through a mapped drive on either a Windows NT or NetWare file server.

You can also use the client software provided with your workstation engine to connect to other server engines on a remote machine as described in the following sections.

Using a Workgroup Engine to Access Local Files and a Remote Server Engine to Access Remote files

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 Pervasive server, you must change the settings in your MicroKernel Router. There are two ways to access these settings: through the Pervasive Control Center and through the Registry Editor.

Accessing the MicroKernel Router Settings Through the Pervasive Control Center

  1. Pull up the Pervasive Control Center (from the Start menu, select Programs, then Pervasive.SQL V8, and Control Center).
  2. Under Control Center Root, double-click Pervasive.SQL V8 engines.
  3. Double-click the icon representing your computer.
  4. Double-click Configuration.
  5. Double-click Client and click on Access.

    The MicroKernel Router settings appear to the right. Be sure the following settings are set correctly:

    Use Remote MicroKernel Engine: On
Use Local MicroKernel Engine: On

Accessing the MicroKernel Router Settings Through the Registry Editor

  1. Go to the Registry Editor (from the Start menu, select Run and type Regedit).
  2. Go to the HKEY_LOCAL_MACHINE\SOFTWARE\Pervasive Software\Microkernel Router\Version 8\Settings directory within the Registry Editor.
  3. The MicroKernel Router settings will appear in the right hand frame of the Registry Editor. Be sure the following settings are set to the following:
    Local: Yes
Requester: Yes

Note
See Advanced Operations Guide for more information on changing settings using the Control Center utility.

Prev
Using Multiple Applications 		Up
Check for Revisions 		Next
Accessing Data on Other Computers


Accessing Data on Other Computers

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.
Table 8-1 Summary of Network Configurations
Configuration | Where to look for more information
Small client/server: Data resides on a single computer where a Workgroup engine is installed. | Setting Up a Small Client/Server Configuration
Peer-to-Peer: Data resides on two or more computers where Workgroup engines are installed. | Setting Up a Peer-to-Peer Configuration
Gateway: Data resides on a file server where no database engine is installed, or it is not running. | Setting Up a Gateway Configuration

Prev
Using a Server Engine and a Workgroup Engine Concurrently 		Up
Check for Revisions 		Next
Using the DOS Requesters


Using the DOS Requesters

How to Use the DOS Requesters to Run DOS Applications

This chapter explains how to use the DOS requesters to run Pervasive.SQL-based DOS applications in Windows. The DOS requesters support Btrieve applications only, not ODBC applications.

  • Overview
  • DOS Box Support on Windows
  • Verifying the DOS Configuration
Prev
Accessing Data on Other Computers
Check for Revisions 		Next
Overview


Overview

Pervasive.SQL V8 supports DOS Btrieve applications in several different ways. The exact method, however, depends on the current configuration and environment of the workstation.

Requesters Available to Access Workgroup Engines

The following choices are available:

  • Win32 DOS Box support: Allows a DOS application to run in a DOS box on a Windows NT/2000 or Windows 9x/ME workstation. This enables direct communication to the Windows 32-bit workstation components rather than to the database engine. This configuration can be used with either a local Pervasive.SQL Workgroup engine, or a remote Pervasive.SQL Server engine. The TCP/IP or SPX protocol supported for client/server access depends on the configuration of the Windows 32-bit components.

Note
DOS Box support must be used for Workgroup engine. This engine does not support the DOS requesters described below.

Requesters Available to Access Remote Server Engines

You can use Win32 DOS Box support described previously to connect to remote server engines. In addition, you can use these other requesters:

  • DOS TCP/IP requester (BREQTCP): Allows a DOS application to run in any Windows DOS box or on a DOS workstation, and communicate to a remote Pervasive.SQL Server engine via the TCP/IP protocol.
  • DOS SPX requester (BREQUEST or BREQNT): Allows a DOS application to run in any Windows DOS box or on a DOS workstation, and communicate to a remote Pervasive.SQL Server engine via the SPX protocol.

Note
BREQTCP, BREQUEST, and BREQNT are explained in Getting Started With Pervasive.SQL (Server edition).

There are different reasons for using these different options, including:

  • Pervasive.SQL V8 Workgroup products support only the Win32 DOS Box configuration.
  • DOS and Windows 3.1x operating systems require the DOS TCP/IP or SPX requesters when accessing a remote server engine.
  • Any given network environment must have only one of the supported protocols available.

Supported Configurations

The table below shows the DOS requester configurations that are supported.
Table 9-1 Supported DOS Requester Configurations
Requester | Workgroup on Windows /98/ME | Workgroup on Windows NT/2000 | Client on Windows 95/98/ME to Remote Server Engine | Client on Windows NT/2000 to Remote Server Engine
DOS Box | ü | ü | ü | ü
BREQTCP | û | û | TCP/IP only | TCP/IP only
BREQNT | û | û | SPX only | SPX only
BREQUEST | û | û | SPX to NetWare only | SPX to NetWare only

Prev
Using the DOS Requesters 		Up
Check for Revisions 		Next
DOS Box Support on Windows


DOS Box Support on Windows

The preferred Requester for Windows is BTRBOX. You can use this Requester even for legacy DOS applications, and for Workgroup applications.

Note
Use the BREQUEST/BREQNT/BREQTCP Requesters ONLY if you experience a problem with BTRBOX. These Requesters are supported for access to Server engines only, not to Workgroup engines.

Win16 and DOS Workstations

The Requesters for non-Win32 boxes are:

  • BREQUEST
  • BREQNT
  • BREQTCP

The following sections document the steps for running DOS applications on Windows NT/2000 and Windows 9x.

Running DOS applications on Windows NT or 2000

All of the components needed to run DOS applications using BTRBOX on Workgroup engine are installed with your client.

After the Windows client component installation, you have everything you need to run a DOS, Windows 16-bit, or Windows 32-bit application. The default DOS application support installed is the Win32 DOS Box configuration.

Using/Disabling Win32 DOS Box Support

Under Windows NT/2000, the DOS Box Install configures the drivers to be completely transparent. Thus, you are able to immediately open a command prompt and run a DOS Btrieve application. The CONFIG.NT file, located in the WINNT\SYSTEM32 directory, contains the command that enables DOS application support. This file is similar to CONFIG.SYS in DOS. Windows NT/2000 loads it for each DOS session opened. In this file, the Install places the following path to load the Win32 DOS Box driver:

DEVICE = C:\PVSW\BIN\BTRDRVR.SYS

To disable the Win32 DOS box support to use the DOS TCP/IP or SPX requester instead

  1. Remove the files BTRDRVR.SYS and BTRVDD.SYS from your system. These files are installed by default in the \pvsw\bin directory.
  2. Edit the CONFIG.NT file (using Notepad) in the folder WINNT\SYSTEM32. Delete or invalidate the line:
    DEVICE=C:\PVSW\BIN\BTRDRVR.SYS

Note
Each configuration (Win32 DOS Box, DOS TCP/IP and DOS SPX Support) is mutually exclusive. You must disable the existing configuration before configuring your machine for a new configuration.

Using DOS TCP/IP Support (BREQTCP)

To use the DOS TCP/IP requester on a Windows NT/2000 workstation, you must first disable the Win32 DOS Box support as described above, and then enable the DOS TCP/IP requester configuration.

Note
You cannot use BREQTCP with a Workgroup engine. It can only be used to connect to a remote server engine.

To enable BREQTCP support on Windows NT/2000

  1. Copy the following six files into your %SystemRoot%\SYSTEM directory. %SystemRoot% refers to your Windows directory, typically C:\WINNT. You can determine the value for %SystemRoot% by opening a DOS box and entering the SET command.
    BREQTCP.EXE
BREQTCP.MSG
JSBDOSWS.EXE
JSBDOSWS.DLL
MSOCKLIB.RC
VSLDOS.INI

Click Start 4 Settings 4 Control Panel.

  2. Double-click System and click the Environment tab.
  3. Add the following environment variable:
    VSL=%SystemRoot%\SYSTEM

Note: There must not be a trailing semicolon in this statement.

Once the DOS TCP/IP requester is setup, use the following steps to run a DOS application:

  1. Start a DOS session.
  2. Run JSBDOSWS.EXE
  3. Load BREQTCP.EXE from the \pvsw\bin directory; this needs to be loaded in each DOS session running a Btrieve application.
  4. Run your application.

    Note: The commands to load JSBDOSWS and BREQTCP can be put in your autoexec.NT file. You can load JSBDOSWS with the Load High command.

To stop a DOS application, unload the requester components by entering the command BREQTCP /u followed by JSBDOSWS /u in the DOS box before closing it.

Using DOS SPX Support (BREQUEST/BREQNT)

Note
You cannot use BREQUEST or BREQNT with a Workgroup engine. They can only be used to connect to a remote server engine.

There are two DOS SPX Btrieve requesters:

  • BREQNT.EXE is the "dual mode" requester that can be used by a DOS application to communicate to either a Windows NT or a NetWare server.
  • BREQUEST.EXE is a NetWare-only version of the DOS SPX requester. This exists for historical purposes before Windows NT support was available, and is still provided because it requires smaller memory than BREQNT. If you are accessing Pervasive.SQL on a NetWare server and if you are running low on DOS conventional memory, you may need to use BREQUEST. If you are accessing a Windows NT server, you must use BREQNT.

In order to use the DOS SPX requester on a Windows NT workstation, you must first disable the Win32 DOS Box support as described above; there are no special steps required to enable the DOS SPX requester configuration.

To run a DOS application with the SPX protocol to a remote server engine

  1. Start a DOS session.
  2. Load BREQNT.EXE or BREQUEST.EXE from the \pvsw\bin directory; this needs to be loaded in each DOS session running a Btrieve application.
  3. Run your application.

To stop a DOS application, unload the requester by entering the command BREQUEST /u or BREQTCP /u in the DOS box before closing it.

Running DOS Applications on Windows 9x/ME

All of the components needed to run DOS applications using BTRBOX on Workgroup engine are installed with your client.

After the Windows client component installation, you will have everything you need to run a DOS, Windows 16-bit, or Windows 32-bit application. The default DOS application support installed is the Win32 DOS Box configuration.

This section explains how to use and disable the DOS Box support on Windows 9x/ME.

Note
Legacy DOS applications must use the BTRBOX configuration on Windows 9X/ME. In fact, it is the only supported configuration with the Workgroup engine products. However, with client/server products, you can run DOS applications with either the BTRBOX configuration, or the legacy 16-bit DOS requesters.

If the DOS application is being run on a DOS or Windows 16-bit operating system, then the legacy 16-bit DOS requesters must be used. BTRBOX works on Windows 32-bit operating systems only.

To run a DOS application with the Win32 DOS Box configuration

  1. Start BTRBOX95:

    Select the BtrBox95 icon to launch from the Start 4 Programs 4 Pervasive.SQL V8 4 Other Utilities menu.

    Load from the \pvsw\bin directory. A minimized dialog appears indicating active support. You must leave this dialog running.

    Closure of this dialog will unload BTRBOX95. You only need to run BTRBOX once—you may have multiple DOS sessions open using a single instance of the driver.

  2. Start a DOS session.
  3. Load BDOSSTUB.EXE from the \pvsw\bin directory; this needs to be loaded in each DOS session running a Btrieve application.
  4. Run your application.

Note You must reboot after the initial installation of the Windows client components in order for the Win32 DOS Box support to function.

A device driver (VxD) is registered and will not load until reboot.

The proper order to stop a DOS application is as follows:

  1. Stop the DOS application.
  2. Close the DOS box.
  3. Stop BTRBOX95.

If you do not follow this order, BTRBOX95 or the database engine may not unload properly.

In situations where stopping and restarting all clients is recommended, you should perform all three steps above. Simply stopping and starting your client applications is not sufficient.

To disable the Win32 DOS box support in order to use the DOS TCP/IP or SPX requester

Note
You cannot use the DOS TCP/IP or SPX requesters with a Workgroup engine. They can only be used to connect to a remote server engine.

  1. Remove the files BTRBOX95.EXE, BDOSSTUB.EXE, and BTRBOX95.VXD from your system; these are installed by default in the \pvsw\bin directory.
  2. Using REGEDIT, remove the following key from your registry:
      HKEY_LOCAL_MACHINE\
        System\
            Current Control Set\
                Services\
                    VXD\
                        BtrBox95

Note
Each configuration (Win32 DOS Box, DOS TCP/IP and DOS SPX Support) is mutually exclusive. You must disable the existing configuration before configuring your machine for a new configuration.

Caution
Editing your registry is an advanced procedure and, if done improperly, could cause you to reinstall your entire computer. If you do not feel comfortable doing this, please obtain the services of a qualified technician. Pervasive cannot accept responsibility for a damaged Registry.

Prev
Overview 		Up
Check for Revisions 		Next
Verifying the DOS Configuration


Verifying the DOS Configuration

To verify that the install completed successfully, you need a pure DOS Btrieve application. One of the simplest application ships with the server engines. You will find BUTIL.EXE in the PVSW\Clients\DOS directory. Running this command by itself will show a list of available commands. Do this one time to ensure the copyright information says Butil for DOS, not Windows NT. You will then want to access a Btrieve file. You can use the BUTIL -STAT command to do this. If the command completes successfully, your DOS support is functioning as designed.

Try a command like this:

BUTIL -STAT f:\pvsw\samples\sample.btr

Here, "f:" is a drive letter mapped to your server and "f:\pvsw\samples\sample.btr" is the path and filename of an existing Btrieve data file. A successful completion will return information about the data file. Otherwise, you will see a status code indicating the problem. Pervasive Technical Support can help you resolve any problems.

Prev
DOS Box Support on Windows 		Up
Check for Revisions 		Next
Configuring the Workgroup Engine


Configuring the Workgroup Engine

How to Take Advantage of Major Workgroup Features

This chapter explains how to get the most out of your Workgroup engine.

  • Overview
  • Setting Up a Small Client/Server Configuration
  • Setting Up a Peer-to-Peer Configuration
  • Setting Up a Gateway Configuration
  • Running the Workgroup Engine as a Service

Prev
Verifying the DOS Configuration
Check for Revisions 		Next
Overview


Overview

This section explains the basic concepts and requirements of Workgroup engines. For additional technical details about the Workgroup engine and the Gateway configuration, please see Advanced Operations Guide.

Installation Requirements

Every computer that may be used to access the same data at the same time must have a Workgroup engine installed on it.

Operating System Security

Only NetWare and Windows database server engines can enforce OS level file security based on the privileges assigned to the login user name. The Workgroup product does not attempt to do this. In a small office, where Workgroup engines are most common, this can be considered a plus because they are usually short on networking experts, and the fewer barriers to successful data access the better.

When to Use Workgroup

There are three main configurations in which you would want to use the Workgroup engine.

Small Client/Server Configuration

See Advanced Operations Guide for additional technical details about Workgroup engine.

The first configuration takes place when all the data is located on a single computer with a Workgroup engine installed, and there is limited sharing of data. Workgroup engine is licensed for up to five concurrent connections, and additional user count licenses may be purchased and applied. This configuration is roughly equivalent to a small client/server configuration.

Peer-to-Peer Configuration

Another situation when you would want to use the Workgroup engine is when the data is distributed among the workstations. This is called a peer-to-peer topology. This configuration is used when each application typically stores much of its own data on the local hard drive, but periodically needs to access data from other workstations or share its own data with others.

In this configuration, each computer shares its data directory or directories. Any computer that needs access to that data maps one or more drives to the shared data directories. Then the Workgroup engine on each computer acts as a mini-server engine to read/write all changes to the data files on that machine.

Gateway Configuration

See Advanced Operations Guide for additional information about setting up a Gateway configuration and about re-directing locator files.

The third topology requiring the use of the Workgroup engine is when the data is stored on a file server where there is no MicroKernel engine. This can be a UNIX server or other type of network file server that gets backed up regularly, but cannot support a MicroKernel engine. In this situation, the first Workgroup engine that opens files in a directory on the server becomes the Gateway to each file in that directory. The other workstations access the data in a client-server fashion through that Gateway engine.

The Gateway engine for a given directory identifies itself by creating a file named ~PVSW~.LOC in that directory. This file is called a Gateway locator file and contains the network name of the computer where the Gateway engine is located. Other Workgroup engines attempting to access this data read the locator file to find the name of the engine they must communicate with in order to access the data.

You can ensure that the same engine always services the files in a given directory by making the locator file read-only. This is called a static gateway, also referred to as a fixed gateway. See To Set up a Fixed Gateway for more information.

The Gateway engine acts as a server engine as it reads and writes pages to the data files, allowing it to make the most use out of its cache. The Gateway feature is designed so that the ownership of any particular directory can change whenever the current gateway engine has no more client applications with any files open in that directory. When the last data file is closed in a directory by a given database engine, the engine releases and deletes the locator file. When the next engine opens a data file, that engine becomes the new gateway to the directory where the data file(s) resides.

What is a Gateway Engine?

A Gateway engine is a Workgroup engine that acts as the sole point of access to all data files in a particular directory on a remote file server. If several Workgroup engines are accessing the same database at the same time, they do not all open the files simultaneously, nor do they share the files. Rather, the first Workgroup engine to access that database becomes the temporary "owner" of those files, and all other Workgroup engines must access the data by contacting the Gateway engine. Only the Gateway engine has the files open and reads/writes the files. The other Workgroup engines act as clients, making requests to the Gateway engine acting as a mini-server engine.

Note
A Gateway engine only comes into play when no database engine is installed on the machine where the data files are, or when the database engine on that machine is not operating.

Multiple Engine File Sharing

Multiple Engine File Sharing (MEFS) is a technology that was used for over a decade in Btrieve workstation engines to share data files. It had a logistical benefit in that each engine worked independently of the other engines. However, each engine had to coordinate it's own actions with any other engine that might be sharing a data file. To perform this task, each engine had to lock bytes in a lock file using operating system locking.

Pervasive chose not to continue with MEFS technology because of some inherent problems. MEFS required a lot of extra network traffic to coordinate access to data by multiple database engines. It also required changes to be written to disk, over the network, as soon as possible so that other engines could get access to those changes. Also, during concurrent user transactions and system transactions, much more of the file was locked than just the portion changed.

Why replace MEFS—Increased Performance

We have found the performance of the Workgroup engine to be dramatically better than version 6.15 workstation engines using MEFS.

The new Workgroup solution uses the well-tested Pervasive client/server technology to allow only one engine to open files at a time. Change operations to files shared by multiple workstations can be over a hundred times faster.

Since only one engine is accessing the data, checkpoints do not have to happen as often to the file, making the best use of the MicroKernel's cache. Disk I/O is greatly reduced, and so is the chance for data corruption.

Our benchmark tests using the TPC-B standard show that, for two or more clients, the Workgroup client-server architecture performs anywhere from 20x to 100x faster than the old standard of MEFS. The TPC-B is a change-intensive test which tracks how fast can we modify the database.

Why replace MEFS—Increased Database Reliability

With MEFS, the chance for lost database changes was greater since database pages needed to be written to the file soon after they were changed so that other engines could gain access to the changes. This situation meant that a lot more data pages were travelling back and forth from the engine to the data file across the network, which greatly increased the chance for corruption.

Prev
Configuring the Workgroup Engine 		Up
Check for Revisions 		Next
Setting Up a Small Client/Server Configuration


Setting Up a Small Client/Server Configuration

As explained in Small Client/Server Configuration , you should use this set up when you have only a few workstations sharing data located on a central computer where you have a Workgroup engine installed.

If you have data located on many computers, or if you do not or cannot install a database engine on the computer where the data is located, you should use one of the other configurations.

To Set Up a Small Client/Server Configuration

  1. You must have the Workgroup engine installed on the computer where the data is, and you must have the Workgroup engine installed on all computers expected to access the data.

    Be sure that the Workgroup engine is in the folder Start 4 Programs 4 Startup on the computer where the data is located. You want to be sure that this engine is operational each time the computer is started, before any other database engines attempt to access the data. By placing the Workgroup engine icon in the Startup folder, you ensure that the database engine is loaded when the computer starts.

 Note You may inadvertently fall into a Gateway configuration if the database engine on the machine where the data is located is not started when the computer is started. If another Workgroup engine attempts to access the data and the local database engine is not running, the other database engine may establish itself as the Gateway for those data files.

You can resolve this situation by shutting down the computer where the data is located, and starting it again, while ensuring that no other computers request data before the local Workgroup engine is restarted. You may need to remove the file ~PVSW~.LOC from the data directory to ensure the Gateway is not re-established.

The best way to ensure that only the Gateway services the file is to set a static gateway locator file using the Gateway Locator Utility.

  2. Share the directory where the data is located so that other computers can map a drive to the data directory.
  3. On each workstation expected to access the data, create an Engine DSN using a drive mapped to the data directory.
  4. Set up is complete. The Workgroup engine on the machine where the data is located now acts as a mini-server, to fulfill all requests for data on that machine.
Prev
Overview 		Up
Check for Revisions 		Next
Setting Up a Peer-to-Peer Configuration


Setting Up a Peer-to-Peer Configuration

As explained in Peer-to-Peer Configuration , you should use this set up when you have workstations sharing local data as well as data located on many different machines, and each machine has the Workgroup engine installed.

This configuration is similar to the small client/server configuration discussed above, except that now every Workgroup engine is sharing data as a server.

If you have data located on only one computers, or if you do not or cannot install a database engine on the computer where the data is located, you should use one of the other configurations.

To Set Up a Peer-to-Peer Configuration

  1. You must have the Workgroup engine installed on each computer where data is located, and you must have the Workgroup engine installed on all computers expected to access the data.

    Be sure that the Workgroup engine is in the folder Start 4 Programs 4 Startup on each computer where data is located. You must be sure that this engine is operational each time the computer is started, before any other database engines attempt to access the data. By placing the Workgroup engine icon in the Startup folder, you ensure that the database engine is loaded when the computer starts.

 Note
You may inadvertently fall into a Gateway configuration if the database engine on a machine where data is located is not started when the computer is started. If another Workgroup engine attempts to access the data and the local database engine is not running, the other database engine may establish itself as the Gateway for those data files.

You can resolve this situation by shutting down the computer where the data is located, and starting it up again, while ensuring that no other computers request data before the local Workgroup engine is restarted. You may need to remove the file ~PVSW~.LOC from the data directory to ensure the Gateway is not re-established.

The best way to ensure that only the Gateway services the file is to set a static gateway locator file using the Gateway Locator Utility.

  2. On each computer where data is located, share the directory where the data is located so that other computers can map a drive to the data directory.
  3. On each workstation expected to access the data, create an Engine DSN using a drive mapped to the data directory.

    Also, create an Engine DSN for any local data that each Workgroup engine needs to access from its own hard drive.

  4. Set up is complete. The Workgroup engine on each machine where data is located now acts as a mini-server, to fulfill all requests for data on that machine.

    Each Workgroup engine also handles any local data access, that is, database requests from applications on that machine for data that resides on the same machine.

Prev
Setting Up a Small Client/Server Configuration 		Up
Check for Revisions 		Next
Setting Up a Gateway Configuration


Setting Up a Gateway Configuration

See Advanced Operations Guide for additional information about setting up a Gateway configuration and about re-directing locator files.

As explained in Gateway Configuration , you should use this set up only when you have data files on a computer where no database engine is installed.

If you have database engines installed on all machines, you should use one of the other configurations.

Note
You may inadvertently fall into a Gateway configuration if the database engine on a machine where data is located is not started when the computer is started. If another Workgroup engine attempts to access the data and the local database engine is not running, the other database engine may establish itself as the Gateway for those data files.

You can resolve this situation by specifying a permanent Gateway as described in this section, or by shutting down the computer where the data is located, and starting it up again, while ensuring that no other computers request data before the local Workgroup engine is restarted. You may need to remove the file ~PVSW~.LOC from the data directory to ensure the Gateway is not re-established.

The best way to ensure that only the Gateway services the file is to set a static gateway locator file using the Gateway Locator Utility.

Floating or Fixed Gateway

You can set up two different Gateway configurations. The default behavior is a floating Gateway configuration. In this configuration, the first engine to open the remote data files becomes the Gateway engine for that directory until all files in the directory are closed. Then the next engine to open the data files becomes the new Gateway. This configuration is the most flexible, but also can entail delays upon initial connection to the database, as the engine tries the different network protocols and checks for an existing Gateway engine.

Note
Using a floating Gateway in a peer-to-peer configuration with multiple shared data sources is not recommended. This configuration is supported and it operates as designed, however, with multiple engines shuffling ownership among multiple data locations, connection delays may be significant. It is also possible to create a situation where a Workgroup engine on a remote machine serves as a the Gateway for data located on your local hard drive. Obviously there is no reason to endure this delay when your local Workgroup engine can serve this data with higher performance.

You can avoid this situation by ensuring that the Workgroup engine on every computer is started when the computer is started. You must also ensure that someone logs on to each computer, because normally the Workgroup engine doesn't start until a user logs on.

You can also avoid this situation by permanently assigning each machine as the Gateway for the data files located on it. See To Set up a Fixed Gateway for information on how to perform this task.

The second configuration is called a fixed or permanent Gateway configuration. In this configuration, a specific engine is permanently assigned as the Gateway engine for a specific directory. If that engine is not running when another engine attempts to access the data, an error code results and the data is not available.

To Set up a Floating Gateway

  1. This is the default behavior. All you need to do is set up an Engine DSN on each Workgroup computer. When creating the Engine DSN for the database, use a mapped drive or a UNC pathname to identify the remote data directory.

    The Gateway assignment now floats dynamically as different Workgroup engines access the remote data.

To Set up a Fixed Gateway

To specify a permanent Gateway engine for a given directory, you need only change the attributes of the ~PVSW~.LOC file to read-only, once it contains the name of the desired engine. There are several ways to perform this task.

Use the Gateway Locator Utility
  1. From the Start menu, choose Programs 4 Pervasive.SQL V8 4 Other Utilities 4 Gateway Locator.
  2. In the Target Directory area, type in or browse for the directory containing the data files for which you wish to set up a permanent Gateway.
  3. In the Directory Status area, click Change. In the dialog box that appears, click Assign a Gateway, then type in or browse for the network name of the computer that you want to be the Gateway. Click OK.
  4. Back in the main Gateway Locator window, check Permanent assignment. Click Exit.
Use the DOS Command Line
  1. Use the ATTRIB +R command at a DOS command prompt to change the attributes of the ~PVSW~.LOC file.

    For example, if your current directory is the directory where the file is located, you can type the following command:

    ATTRIB +R ~PVSW~.LOC
Use the Windows Explorer
  1. Right-click on the ~PVSW~.LOC file in the directory for which you want to make a permanent Gateway assignment. Choose Properties from the pop-up menu.
  2. In the Properties window, on the General tab, click Read-only in the section labeled Attributes. Click OK.

Working with the Gateway Locator Utility

The Gateway Locator Utility provides control of and insight into any Gateway configuration you have on your network. This section explains how to use the utility for a variety of purposes.

This utility enables users to determine or change the Workgroup Engine which is being used as the gateway for the data files in a particular directory. The Gateway Locator utility is used only with Pervasive.SQL V8 Workgroup Engine.

The Gateway Locator operates by reading and manipulating the locator file, ~PVSW~.LOC, which resides in any directory which is assigned a Gateway engine. If this file is locked (in use), the Gateway Locator can only locate, not change, the Workgroup engine being used as a Gateway for that particular directory.

To start the Gateway Locator, From the Start menu, choose Programs 4 Pervasive.SQL V8 4 Other Utilities 4 Gateway Locator. The following dialog box appears:

Figure 10-1 Gateway Locator Main Dialog Box

In the Target Directory box, enter the path of the directory which contains the data files for which you wish to locate or change the Gateway engine. The default target directory is the current working directory. Clicking the "..." button allows you to browse for the target directory, by bringing up the following dialog box:

Figure 10-2 Gateway Locator Browse Dialog Box

Locating the Gateway Workgroup Engine

Once the target directory is selected, clicking the Refresh button causes the name of the Gateway engine for that directory (if such exists) to appear in the "Gateway Assigned To" box. If no Gateway exists for a particular directory, the box reads "unassigned".

Changing the Gateway Workgroup Engine

Once the target directory is selected, clicking the Change button allows you to choose the Workgroup engine which you wish to serve as Gateway for a particular directory (this button is disabled if the locator file for that directory is locked.) The following dialog appears:

Figure 10-3 Gateway Assignment Dialog Box

You may enter the name of the machine you wish to serve as gateway, or click on the "..." to browse for it. The following dialog box appears:

Figure 10-4 Browse for Computer Dialog Box

Prev
Setting Up a Peer-to-Peer Configuration 		Up
Check for Revisions 		Next
Running the Workgroup Engine as a Service


Running the Workgroup Engine as a Service

You may configure your workstation to run the Workgroup engine as a service rather than as a console application. This allows the engine to start automatically when the operating system starts. A user is not required to log in to start the engine.

No tray icon appears when you run the Workgroup engine as a service.

Configuration

Refer to the following Pervasive.SQL Knowledge Base articles for the steps to run the engine as a service.
Operating System | Knowledge Base Article
Windows 9x Millennium | http://support.pervasive.com/eSupport/publisher.asp?id=64b7ab3f-be4f-11d5-b25a-00508b5d6b61 or perform a Knowledge Base search on: "Configure Workgroup or Workstation Engine to run as a Service under Windows 9.x or Millennium ".
Windows NT Windows 2000 Windows XP | http://support.pervasive.com/eSupport/publisher.asp?id=c11d9d94-bc34-11d5-b259-00508b5d6b61 or perform a Knowledge Base search on: ""Configure Workgroup or Workstation Engine to run as a Service under Windows NT, 2000, XP".

Note that on Windows NT, 2000, and XP, a valid user name and password are required to access Pervasive.SQL databases on another machine. "System Account" has no rights on other machines to Pervasive.SQL databases.

If you want the Pervasive Workgroup service to access databases on another machine, then you must specify a valid user name and password for the other machine. Access the properties for the Pervasive Workgroup service. (Double-click the service on the Services dialog.) Check the option This Account on the Log On As section and specify a valid user name and password.

Stopping the Service

To stop the service on Window 9x and Millennium you must remove the service from the RunServices registry setting. For example, you would delete the string value Pervasive.SQL V8 Workgroup (or whatever you named the string) and its data, C:\Pvsw\Bin\ W3dbsmgr.exe -SRDE -SERVICE, from HKEY_LOCAL_ MACHINE\Software\Microsoft\Windows\CurrentVersion\ RunServices. If you want to stop and then restart the service (and not permanently remove the service), then just reboot the machine.

You stop the service on Windows NT, 2000, and XP just as you would any other service.

Stopping the Engine as a Service on Windows NT, 2000, and XP

  1. Open the Services dialog. For example, on Windows NT, click Start > Settings > Control Panel, then double-click Services.
  2. Click on the service name that you assigned to the Workgroup engine. This is the string name you designated when you modified the registry as explained in the Knowledge Base article. For example, if you used the name suggested in the article, click on Pervasive.SQL Workgroup.
  3. Click Stop, then Close.
  4. Click OK.

Prev
Setting Up a Gateway Configuration 		Up
Check for Revisions 		Next
After Installation


After Installation

Prev
Running the Workgroup Engine as a Service
Check for Revisions 		Next
Connecting Clients to a Pervasive.SQL Database


Connecting Clients to a Pervasive.SQL Database

How to Connect Clients to the Sample Database on a Pervasive.SQL Workgroup Machine

A sample database called DEMODATA is included on every Pervasive.SQL V8 installation. This chapter shows how to use a Pervasive.SQL V8 client to:

  • Connect to a machine that is running a Pervasive.SQL engine.
  • Use the Pervasive Control Center to find the DEMODATA database.
  • Access information in DEMODATA tables using Pervasive Control Center.

This chapter contains the following sections:

  • Basics About Pervasive.SQL Servers and Clients
  • Connect a Client to a Pervasive.SQL Server
  • Use the Client to Obtain Data from the Server
  • Become an Expert User
Prev
After Installation
Check for Revisions 		Next
Basics About Pervasive.SQL Servers and Clients


Basics About Pervasive.SQL Servers and Clients

You should note the following about Pervasive.SQL servers and clients.

Every Engine is Also a Client

  • The client components of Pervasive.SQL V8 are installed with every server install. So if you have a Pervasive.SQL V8 Workgroup engine installation, you can use your machine to connect to other servers as a client.

Clients

  • You can use Pervasive Control Center to connect to remote machines on which a server engine of Pervasive.SQL V8 is installed.
  • You will need to login as an administrative user on the remote server to perform most functions. This means that you must have full administrator-level rights on the remote server or be a member of the Pervasive_Admin group defined on the remote server.
Prev
Connecting Clients to a Pervasive.SQL Database 		Up
Check for Revisions 		Next
Connect a Client to a Pervasive.SQL Server


Connect a Client to a Pervasive.SQL Server

  1. Start PCC

    Click Start 4 Programs 4 Pervasive.SQL V8 4 Control Center

  2. Register a Server Engine in your Namespace.

    Right-click on Pervasive.SQL Engines (displayed in your namespace) and select Register New Engine.

    The Namespace is the column on the left side of the Control Center window that contains a list of machines to which you are connected.

 Note
The machines listed in your namespace will remain between Control Center sessions. To remove a machine, right-click on the machine name and select Delete.

Figure 11-1 Registering a New Engine

A dialog is displayed that allows you to choose the machine name where the Pervasive.SQL V8 database engine resides.

Figure 11-2 Choosing a Computer Name

  3. If you are unsure of the computer name, click the button to the right of the name field and select a computer name from the Network list that appears.

Figure 11-3 Choosing a Computer Name

  4. Click OK to add the machine to your namespace, or click Test to test the connection first.
  5. You need to be authenticated on the remote server, and a dialog displays prompting you for a user name and password. Enter the values in the appropriate field and click OK.
  6. You are now connected to the remote Pervasive.SQL server.
Prev
Basics About Pervasive.SQL Servers and Clients 		Up
Check for Revisions 		Next
Use the Client to Obtain Data from the Server


Use the Client to Obtain Data from the Server

Once you are connected to the database:

  1. Expand the Databases list for your server as shown in Figure 11-4 .

Figure 11-4 Expanding the Databases List for a Machine

  2. Find DEMODATA in the list and click on the plus (+) sign.
  3. Select Tables from the list.
  4. Click on the table DEPARTMENT as shown in Figure 11-5 .

Figure 11-5 Selecting the DEPARTMENT Table in DEMODATA

  5. By default, a "SELECT * FROM" query is run and the table results are displayed in an active grid as shown in Figure 11-6

    The active grid that loads when your data is displayed is updateable. That is, changes you make to the data in that grid are stored to the database.

    If you wish to browse the data without the risk of accidentally updating data, click the Text Results tab at the lower-left of the SQL Data Manager window, as shown in Figure 11-6.

Figure 11-6 Displaying the DEPARTMENT Table in DEMODATA

  6. Refine your query

    To show how to modify a basic query, restrict the results to only departments that start with the letter 'M' by altering the query at the top half of the screen and clicking the Execute Query button, which is shown in Figure 11-6.

    SELECT * FROM Department WHERE Name LIKE 'M%'

    You can see the results of the query in Figure 11-7 .

Figure 11-7 Refining Your Query - DEPARTMENT Table in DEMODATA

Prev
Connect a Client to a Pervasive.SQL Server 		Up
Check for Revisions 		Next
Become an Expert User


Become an Expert User

Now that you can do some basic database access using Pervasive Control Center, you may want to continue learning about other features.

Users's Guide

This manual contains an overview of the Pervasive Control Center and instructions for performing basic tasks.

Advanced Operations Guide

This manual contains advanced operating and maintenance tasks, including database operations.

Prev
Use the Client to Obtain Data from the Server 		Up
Check for Revisions 		Next
Installation Troubleshooting


Installation Troubleshooting

How to Proceed When You Encounter Errors During Installation

Pervasive Software provides several features and tools in Pervasive.SQL V8 that help to prevent configuration and installation problems.

Some of these utilities are installed and run as part of the installation process and all can be run later to evaluate configuration and registry settings and to troubleshoot problems. They are shown in Table 12-1 .

This chapter contains the following sections:

  • Troubleshooting Tools
  • Troubleshooting Strategies
  • Configuration for Special Installation Situations
  • Diagnosing Problems with Pervasive System Analyzer (PSA)
  • Verifying Database Engine is Running
  • Obtaining File, Client, and Engine Version Number
  • Troubleshooting Common Pervasive.SQL V8 Issues
  • Issues After Uninstalling Pervasive.SQL on Windows
  • Engine and Client Version Conflicts
  • How to Get Additional Help
Prev
Become an Expert User
Check for Revisions 		Next
Troubleshooting Tools


Troubleshooting Tools

The following table describes some tools that can help you avoid or solve problems.
Table 12-1 Pervasive Tools that Assist in Installation and Problem Determination
Feature/Component | Function | For More Information
Pervasive System Analyzer | Analyzes system components, runs communication tests, and archives or restores previous database engine files on your system. | See Diagnosing Problems with Pervasive System Analyzer (PSA) .
Gateway Locator | A utility which can be used to determine or change the Gateway being used for a particular data dictionary (only in Pervasive.SQL V8 Workgroup Edition.) | See Configuring the Workgroup Engine .
Smart Components | Smart Components is an internal design in Pervasive.SQL that ensures that Pervasive software components always load with compatible components. | Refer to Advanced Operations Guide.
Knowledge Base | Provides information about many Pervasive software configurations and common environments. | Search the Pervasive Knowledge base at: http://support.pervasive. com/eSupport

Prev
Installation Troubleshooting 		Up
Check for Revisions 		Next
Troubleshooting Strategies


Troubleshooting Strategies

Pervasive Software hopes that your installation process completes without experiencing any problems. However, this depends on a number of factors, including proper network support, and operating system configuration.

If something does go wrong during an installation, Pervasive offers some tools that can help in diagnosing the problem. This chapter explores some of the troubleshooting techniques that you can use.

Note
If the installation fails before the program copies any files to the target installation directory, the installation log file (install.log) can be found in the directory specified by the %TEMP% environment variable. This directory is often c:\windows\temp or c:\winnt\temp.

Checklist for Problems

  • Did you see any error messages displayed during installation?
  • Does the Network function correctly?
  • Is the Engine running?
  • Is the Client software correctly functioning?
  • Are there errors in your PVSW.LOG file?

Troubleshoot the Problem

The rest of this section contains procedures that you can use in verifying your installation.

  • Diagnosing Problems with Pervasive System Analyzer (PSA)
  • Verifying Database Engine is Running
  • Obtaining File, Client, and Engine Version Number
  • How to Get Additional Help
Prev
Troubleshooting Tools 		Up
Check for Revisions 		Next
Configuration for Special Installation Situations


Configuration for Special Installation Situations

This section lists some scenarios where the default configuration settings for Pervasive.SQL need adjusting for proper database operation.

The following table summarizes some of these situations. If you find that your configuration matches an issue, please see the reference included for more information.

If your computing environment includes...
Then you need to:
Microsoft Active Directory Service
Read the following section:
Support for Active Directory Service
Multiple network interface cards (NICs)
Enable a configuration setting for Multi-homed setting
In Advanced Operations Guide, see:
  • TCP/IP Multihomed
  • Listen IP Address
NetWare 5.x servers
Increase the default Cache Allocation size. NetWare 5.x includes Pervasive.SQL and Novell set the default cache size to 1MB, which is too small for most applications.
  • See Cache Allocation Size for more information.
A network that is subject to outages
Enable a configuration setting that tries to auto-reconnect to a server when a network outage occurs
  • In Advanced Operations Guide, see Pervasive Auto-Reconnect .
Database files that have embedded spaces
Enable a configuration setting that instructs Pervasive.SQL to accept files with embedded spaces.
  • In Advanced Operations Guide, see Embedded Spaces

Prev
Troubleshooting Strategies 		Up
Check for Revisions 		Next
Diagnosing Problems with Pervasive System Analyzer (PSA)


Diagnosing Problems with Pervasive System Analyzer (PSA)

Pervasive System Analyzer is a diagnostic utility included with Pervasive.SQL V8.

Pervasive System Analyzer (PSA) is conveniently integrated into the product installation and available as a stand-alone diagnostic tool to help you with a the following tasks:

  • Troubleshoot network problems
  • Detect previous installations of Btrieve or Pervasive.SQL on your system
  • Note other factors that influence your networking environment
  • Perform archives and/or restorations of previously-installed versions of Pervasive.SQL
  • Delete components or previous archived versions
  • View current component set and versions

PSA replaces the features that were previously offered by SmartScout and InstallScout.

How to Start PSA

To start PSA

  1. Click Start, and point to Programs 4 Pervasive System Analyzer.

Documentation for PSA

The use of Pervasive System Analyzer is detailed in Pervasive.SQL User's Guide. Please see Pervasive System Analyzer (PSA) of Pervasive.SQL User's Guide for complete information regarding Pervasive System Analyzer

SmartScout Replaced by PSA

Note
SmartScout was replaced by Pervasive System Analyzer starting in Pervasive.SQL 2000i Service Pack 3. The documentation on SmartScout has been removed.

Prev
Configuration for Special Installation Situations 		Up
Check for Revisions 		Next
Verifying Database Engine is Running


Verifying Database Engine is Running

To verify that the Pervasive.SQL V8 server engine is running:

To Start the Pervasive Workgroup engine:

  1. Click Start 4 Programs 4 Pervasive.SQL V8 4 Engines.
  2. Select the Pervasive.SQL Workgroup Engine icon.

    By default, the MicroKernel allocates resources and is ready to service local application database requests.

To Stop the Pervasive Workgroup engine:

  1. On the Windows taskbar, right-click the Pervasive Database icon.

  2. Select Stop Engines and Exit.

Note
You will receive a warning message when trying to stop the engine if any of the following is true:

    • There are active clients.
    • No activity took place since the engine loaded.
    • 10 seconds has not elapsed since the last operation took place.
Prev
Diagnosing Problems with Pervasive System Analyzer (PSA) 		Up
Check for Revisions 		Next
Obtaining File, Client, and Engine Version Number


Obtaining File, Client, and Engine Version Number

You can use Pervasive.SQL utilities to verify that the client and engines have the version number you expect, or to check the version of a particular file.

Determining Client and Engine Version

You can check the engine and client versions using Function Executor on Windows platforms or using the BUTIL command-line utility on all platforms:

Using Function Executor

  1. Load the Function Executor Utility.

    Click Start 4 Programs 4 Pervasive.SQL V8 4 Other Utilities 4 Function Executor

    Function Executor is a utility that simulates Btrieve client operations using the Pervasive.SQL requesters.

  2. Select the Btrieve Version Info button, which appears as a clock icon. The correct button is shown in Figure 12-1.

Figure 12-1 Selecting the Btrieve Version button

  3. After choosing the Btrieve Version Info button, a dialog displays that indicates the version of the client requesters and the engine.

Figure 12-2 Btrieve Version Info Display

Using the BUTIL Utility

From a command prompt, enter the following:

BUTIL -VER

The requester and engine versions are then displayed.

Determining a File Version

You can determine the file version of a MicroKernel data file using the Pervasive Control Center or Function Executor on Windows platforms, or using the BUTIL command-line utility on any platform:

  • Using the Pervasive Control Center to select the properties of a table.
  • Using Function Executor to open and then query the version of a file.
  • Using BUTIL command-line utility to query the statistics of the file.

Using the Pervasive Control Center

You can use the Pervasive Control Center to perform this task.

To Determine the File Version of a Table Using Pervasive Control Center

  1. Click Start 4 Programs 4 Pervasive.SQL V8 4 Control Center
  2. Find the database by expanding its name in the Control Center namespace on the left.
  3. Right-click on a table name and select Properties as shown in Figure 12-3.

Figure 12-3 Obtaining a File Version with the Pervasive Control Center

  4. The table properties are displayed, which includes the file version of the underlying MicroKernel data file.

Figure 12-4 Table Properties Page

Using Function Executor

The Function Executor utility can simulate Btrieve operations and can be used to determine the file version by performing the following operations:

  1. Open (0)
  2. Version (26)

The Function Executor utility is documented in more detail in Advanced Operations Guide.

Using BUTIL command-line utility

Use the -stat parameter of BUTIL to query the file statistics, which includes information about:

  • File version
  • Pages
  • Records
  • Keys

Type the following at a command prompt:

butil -stat <filename>

For example, to query the statistics of the file DEPT.MKD of the DEMODATA database included with Pervasive.SQL:

butil -stat dept.mkd

The BUTIL utility (available on Windows, NetWare, and Linux) is documented in more detail in Advanced Operations Guide.

Prev
Verifying Database Engine is Running 		Up
Check for Revisions 		Next
Troubleshooting Common Pervasive.SQL V8 Issues


Troubleshooting Common Pervasive.SQL V8 Issues

This section outlines problems you may encounter during the installation or when first using the Workgroup product.

I fail to see the effects of my configuration changes.

Try stopping and then restarting the database engine. Whenever you make a change to engine configuration components, you must stop and restart the database engine for the changes to take effect. For information on how to start and stop the database engine, see Verifying Database Engine is Running .

Why do I (now) receive Status 95, after running my application successfully?

Your application has lost its session with the database engine. This can happen if you make changes to your configuration settings and must restart the database engine, as in the troubleshooting example given above. At the moment the database engine is stopped, any application that is running loses its session with the database engine. You must stop all those utilities and restart them in order to reestablish communication.

See the Status Codes and Messages manual for more cases in which this status code can be returned.

Installing a Pervasive.SQL application has rendered another application unusable.

If the latest DLLs have been overwritten, it is possible to restore the overwritten DLLs using a backup directory that is automatically created when you install Pervasive.SQL V8.

Pervasive.SQL uses a system called Smart Components to avoid component mismatches and the occurrence of an older program overwriting newer components. To provide an interface for legacy applications, however, some component names are still capable of being overwritten.

To restore the compatibility DLLs:

  1. Open the directory C:\WINDOWS\SYSTEM\BTCOMPAT.BCK.
  2. Copy the files located inside this directory to your Btrieve requester's system directory. For example, C:\WINDOWS\SYSTEM for a Windows 95 machine or C:\WINNT\SYSTEM32 for a Windows NT/2000 machine.

Note
You only need to perform this procedure if your Pervasive.SQL engine was made inoperable by installing an incompatible or outdated application.

How do I verify that my DOS components are functioning properly?

Pervasive provides a DOS version of BUTIL.EXE in C:\PVSW\BIN\DOS for purposes of verifying that your DOS components are functioning properly.

To verify using the DOS version of BUTIL:

  1. Enter the following at a DOS prompt:
cd \pvsw\bin\dos
butil -stat ..\..\samples\sample.btr

In addition, use of the BDOSSTUB.EXE is needed for some applications using Windows 95 DOS Box for Btrieve if you encounter a Status 20, indicating the requester is not loaded. Some applications built with Turbo Pascal have this problem, which can be avoided by loading the BDOSSTUB.EXE TSR before starting the DOS application.

Why can't I restart my application after an improper program exit?

Database engine components may remain in memory if the engine is interrupted improperly.

If you cannot restart your program after improperly aborting the application by using Ctrl-C or stopping the process:

  1. Shut down and restart your system.
  2. Avoid terminating applications in an abnormal manner.

Why isn't my application using the Workgroup engine?

If you previously installed Pervasive.SQL requesters and later installed the Pervasive.SQL V8 Workgroup engine but your application is only using the requesters, you may have an outdated configuration that sets Local Access to Off. The Pervasive.SQL V8 Workgroup engine's installation does not overwrite existing settings. To reset Local Access to On, see Using a Workgroup Engine to Access Local Files and a Remote Server Engine to Access Remote files .

I have previously installed requesters and then Pervasive.SQL V8. How do I resolve a Status 3012 returned while running a 16-bit application?

A 16-bit Pervasive.SQL application that functions properly going to a remote server will require an adjustment when running against the Workstation engine. The Pervasive.SQL Workgroup engine requires that 16-bit applications use the ODBC thunk mechanism.

Thunking with the Microsoft-provided ODBC thunk DLLs is required for remote Pervasive.SQL engine access from a Win16 ODBC application running on a Win32 workstation.

You may also receive a Status 802 from the Workgroup engine in this scenario.

Status Code 3012 (Local engine is not accessible to the MicroKernel router) can be corrected by examining your Thunk settings.

How to set up Win16 Applications to use 32-bit Components (Thunking):

  1. On the Start menu, go to:
    Programs 4 Pervasive.SQL V8 4 Control Center.
  2. Double-click Pervasive.SQL Engines and double-click the icon representing your client computer.
  3. Double-click Configuration and double-click Client-16 bit.
  4. Click on Access, and in the right-hand pane, right-click Use Thunk and make sure it is set to On.
  5. In the right-hand pane, right-click on Use Remote MicroKernel Engine and ensure that it is set to Off.
  6. Click on Use Local MicroKernel Engine and ensure that it is set to Off.

Because the Remote and Local parameters are both set to Off, the application passes control to the "Thunking Layer." After this procedure is completed, your Win16 applications use Win32 components to access the database engine.

I do not see the Configuration Utility when I open the PCC. How do I display this utility?

To display the Configuration Utility from inside the PCC:

  1. Ensure that you are connected to the proper server.
  2. Double-click Pervasive.SQL Engines.
  3. Double-click the desired database engine icon.
  4. Configuration is one of the options under the desired server name.

How Do I Access the Pervasive.SQL V8 Online Manuals?

If you wish to read the online documentation:

  1. On the Start menu, choose:
    Programs 4 Pervasive.SQL V8 4 Documentation 4 Pervasive.SQL V8.
  2. Click on the desired manual under the Contents tab or search for a topic.

Note
Pervasive.SQL V8 Documentation is in the form of HTML Help for Win32 platforms. You can also view the documentation in the form of Adobe Acrobat (PDF) files. These PDF files and an installation program for an Acrobat reader is available on the Pervasive.SQL CD-ROM. Alternately, the reader may be downloaded from http://www.adobe.com.

I received an error message during installation that begins: "Setup did not update the PATH statement in autoexec.bat because the new path would be too long for Windows."

This message appears when the installation program cannot update the PATH environment variable because the resulting PATH definition would be too long (exceeds the environment space). For info on how to increase the environment space defined in config.sys, see the Microsoft knowledge base article:

http://support.microsoft.com/?kbid=230205

If you get this error message, than a REM statement (a comment) has been added to your autoexec.bat file. The REM statement contains the PATH value that would have been entered. You can change the PATH statement manually.

The best approach, if possible, is to install the product at a location with a shorter installation directory so that the value of PATH does not exceed the environment space.

Prev
Obtaining File, Client, and Engine Version Number 		Up
Check for Revisions 		Next
Issues After Uninstalling Pervasive.SQL on Windows


Issues After Uninstalling Pervasive.SQL on Windows

When you uninstall Pervasive.SQL using the Add/Remove Programs mechanism in Windows, you should not have any database engine files remaining on your system. However, some actions such as installing multiple times to the same machine or restoring archived components can cause a significant number of files to be left on your system. This is a side effect of how the installation process works with the Windows operating system and can be corrected using Pervasive System Analyzer (PSA).

In the situations described previously, the files are left because Windows has the files marked with usage counts that indicate that they are being used by more than one program, and therefore the uninstallation program does not remove them from your system. This is expected behavior, but it may lead you to conclude that the Pervasive.SQL uninstall program is not functioning correctly.

In order to correct this condition, run the PSA Delete function and remove all Pervasive components from your system. PSA deletes the files and the Windows registry entries that caused the files to remain on your system. At that point, you should have a system that is free of Pervasive.SQL components, and the next installation of Pervasive.SQL will have correct usage counts.

For information on how to use the PSA Delete function, see Pervasive System Analyzer (PSA) in Pervasive.SQL User's Guide.

Prev
Troubleshooting Common Pervasive.SQL V8 Issues 		Up
Check for Revisions 		Next
Engine and Client Version Conflicts


Engine and Client Version Conflicts

If you update your engine to the latest Pervasive.SQL version without also updating your client requesters, you will encounter warning messages from Pervasive.SQL indicating the version conflict. The message displayed is:

An engine to client component mismatch was found

When you receive such a message, it is also logged to your Pervasive Event Log (PVSW.LOG).

This message is only a warning. The client is not prevented from connecting to the engine in this situation. It simply recommends that you upgrade your clients as soon as it is feasible in order to obtain the best performance and reliability from your Pervasive.SQL database product.

If circumstances in your organization dictate that you cannot upgrade the clients for some time, you may want to disable the dialogs that appear when your client components are activated. However, you cannot disable the entries in the Pervasive Event Log, and you should note that over time this log could grow to a large size as these entries are logged.

To permanently solve the problem, update your client requesters to the same version as your server engine.

Disabling the Client Mismatch Warning Messages

To disable the client component mismatch error

  1. On the client with the older version of Pervasive.SQL, go to the Registry Editor (from the Start menu, select Run and type Regedit).
  2. Go to the HKEY_LOCAL_MACHINE\SOFTWARE\Pervasive Software\Microkernel Router\Version 7\Settings directory within the Registry Editor.
  3. The MicroKernel Router settings will appear in the right hand frame of the Registry Editor. Add a new string value Engine Version Check and give it a value of No.

    Caution
    Use care when editing the Windows registry.

Prev
Issues After Uninstalling Pervasive.SQL on Windows 		Up
Check for Revisions 		Next
How to Get Additional Help


How to Get Additional Help

Pervasive Software strives to ensure that your product installation is easy and successful. If you encounter problems during the installation that are not covered in this manual, please contact Pervasive Software in one of the following ways and we will address your problem promptly.

For general questions, common problem resolution, client/server issues, your first line of support should be the Pervasive Software Knowledge Base, a web-based searchable index of all Pervasive technical information: http://support.pervasive.com/eSupport.

For developer-related issues, visit the following web sites:

  • Pervasive Developer Center
    http://www.pervasive.com/developerzone
  • TechWire and NewsWire are e-mail based newsletters on all things Pervasive: learn about Beta cycles and releases, Service Pack releases, current topics, FYIs, Q & As, Pervasive Software events in your area, trade shows where you can find us, and much more!

    To subscribe to these e-mail newsletters, visit the Subscription Center at http://www.pervasive.com/support/subscription.asp.

If your installation is not successful, or you encounter problems not documented in the Pervasive.SQL manuals or on the Knowledge Base, contact Pervasive Software Customer Support in one of the following ways:

You may obtain technical support from the following Web-based support options:

    • Pervasive Knowledge Base at http://support.pervasive.com/eSupport
    • To open a support incident, http://www.pervasive.com/support/index.asp. Click on Open an Electronic Incident.
    • To report a product defect, http://www.pervasive.com/support/index.asp. Click on Report a product defect.

If you require something other than what Web-based support options provide, contact Pervasive Support by phone:

    • 800-287-4383 option 3 (the Americas)
    • CIC: +00.800.1212.3434 (Belgium, France, Germany, Italy, Luxembourg, The Netherlands, Spain, Sweden, Switzerland, and the U.K)
    • CIC: +32.0.23.37.61 (Any other European, Middle Eastern, African or Asian countries, excluding Japan)

For technical support and discussions about Pervasive products in general:

    • Visit the DevTalk forum at http://www.pervasive.com/devtalk.
  • Visit http://www.pervasive.com/company/contact/index.asp for other contact information.

Thirty-Day Free Technical Support

If you still have questions or problems relating to your Pervasive.SQL V8 installation, you can obtain help from the Pervasive Customer Support department.

Your purchase of Pervasive products entitles you to 30 days of free technical support for installation and configuration problems.

See the following section, Additional Resources for information on how to contact Pervasive Software Customer Support.

Prev
Engine and Client Version Conflicts 		Up
Check for Revisions 		Next
Additional Resources


Additional Resources

A Guide to Pervasive.SQL Customer Information Resources

Pervasive Software strives to ensure that your experience with Pervasive.SQL is successful. This chapter describes the resources and information available to you as a valued customer of Pervasive Software.

The following variety of resources can help you get answers to your questions, troubleshoot problems, and interact with the Pervasive team as well as with other customers:

  • Printed Documentation
  • Developer Center
  • Pervasive.SQL Knowledge Base
  • FTP Site
  • Online Documentation
  • Subscription Based E-mail Services
  • DevTalk
  • Newsgroup
  • E-Mail Contacts
  • Technical Support

Prev
How to Get Additional Help
Check for Revisions 		Next
Printed Documentation


Printed Documentation

Pervasive.SQL V8 comes with a printed copy of Getting Started and Status Codes Quick Reference. A complete suite of online documentation is installed on Windows when you choose the Complete installation procedure. It is available as an option in the Custom installation procedure. The content is accessible through the Start menu:
Programs 4 Pervasive.SQL V8 4 Documentation 4 Pervasive.SQL V8.

Printed versions of the following titles are available for purchase:

  • Getting Started with Pervasive.SQL (Server or Workgroup edition)
  • Pervasive.SQL User's Guide
  • SQL Engine Reference
  • Status Codes and Messages
  • Pervasive Products and Services
  • Advanced Operations Guide
  • What's New in Pervasive.SQL (for latest release)

To order manuals, please contact Pervasive Software using one of the following methods:

Online through the Pervasive Store: http://www.pervasive.com/commerce

E-mail: salessupport@pervasive.com

Phone: 1-800-287-4383

Prev
Additional Resources 		Up
Check for Revisions 		Next
Developer Center


Developer Center

The Pervasive Software Web site is a great source for Pervasive.SQL information: http://www.pervasive.com. It is your most immediate source for assistance with the product.

The link shown below is commonly referred to as Developer Center. It is a great starting point from which to navigate to available downloads, documentation, product updates, news articles, sample code and tutorials. Developer Center also provides access to an expansive technical library and training information.

http://www.pervasive.com/developerzone/

Prev
Printed Documentation 		Up
Check for Revisions 		Next
Pervasive.SQL Knowledge Base


Pervasive.SQL Knowledge Base

The Pervasive.SQL Knowledge Base Online is a searchable database for technical information regarding installation, configuration, component management, product defect status, and answers to the frequently asked questions (FAQs). The Knowledge Base, shown below, uses an associative problem-solving technology to perform contextual searches and can be used to quickly find specific answers to your questions about Pervasive products.

http://support.pervasive.com/eSupport/

Prev
Developer Center 		Up
Check for Revisions 		Next
FTP Site


FTP Site

Pervasive Software strives to maintain close ties to developers using Pervasive.SQL for their database applications. On the Pervasive FTP site, you can find practical resources such as downloadable updates and patches to our product offerings as well as additional debugging tools, documentation, third-party tools, and beta releases.

ftp://ftp.pervasive.com/support/

Prev
Pervasive.SQL Knowledge Base 		Up
Check for Revisions 		Next
Online Documentation


Online Documentation

The latest versions of Pervasive.SQL product manuals in CHM, HLP and PDF format are available for download from the Pervasive Software web site. These titles include:

  • Getting Started with Pervasive.SQL (Server or Workgroup edition)
  • What's New in Pervasive.SQL (for current release)
  • Pervasive.SQL User's Guide
  • SQL Engine Reference
  • Status Codes and Messages
  • Pervasive Products and Services
  • Advanced Operations Guide

http://www.pervasive.com/support/technical/online_manuals.asp

Pervasive Library

You can also view all the current documentation online, along with technical papers, discussion forums, and other resources.

http://www.pervasive.com/library

Prev
FTP Site 		Up
Check for Revisions 		Next
Webinars


Webinars

Pervasive Software offers a series of Webinars (web-based seminars) that are focused on singular subjects and have been designed to maximize the transfer of knowledge to our partners and developers without expense of travel.

This forum also offers opportunities for live contact with subject matter experts from Pervasive Software in lively discussions during informal and open question-and-answer periods provided throughout the conferences.

For more information, see http://www.pervasive.com/training/calendar/index.asp.

Prev
Online Documentation 		Up
Check for Revisions 		Next
Subscription Based E-mail Services


Subscription Based E-mail Services

TechWire and NewsWire are newsletters on all things Pervasive: learn about Beta cycles and releases, Service Pack releases, current topics, FYIs, FAQs, Pervasive Software Events in your area, trade shows where you can find us, and much more!

To subscribe to these free e-mail services, see the following website.

http://www.pervasive.com/support/subscription.asp

Prev
Webinars 		Up
Check for Revisions 		Next
DevTalk


DevTalk

Pervasive Software's DevTalk discussion forums are a great way to share ideas with other customers, get technical questions answered, and give feedback directly to Pervasive Software.

http://www.pervasive.com/devtalk/

Prev
Subscription Based E-mail Services 		Up
Check for Revisions 		Next
Newsgroup


Newsgroup

Many Pervasive.SQL customers enjoy participation in a newsgroup—a learning environment in which users help users, with some participation by Pervasive Software. The newsgroup is managed by the end-user community, posting and answering questions as they wish.

Pervasive Software is represented in the worldwide network of news discussion groups at:

news://comp.databases.btrieve.

Prev
DevTalk 		Up
Check for Revisions 		Next
E-Mail Contacts


E-Mail Contacts

Pervasive Software welcomes your comments, suggestions and requests for assistance via e-mail. Please submit to the following contacts:

  • docs@pervasive.com

    For comments or concerns regarding the content of Pervasive.SQL documentation. Requests for manuals should be directed to your sales rep or "salessupport@pervasive.com".

  • uteam@pervasive.com

    For comments or concerns regarding the Pervasive.SQL utilities, such as PCC, PSA, installation, and other Pervasive tools.

  • salessupport@pervasive.com

    For information about Pervasive.SQL sales matters such as contacts, pricing, and product specifications.

  • developer@pervasive.com

    For developer relations. A great way for developers to communicate their ideas about all Pervasive products, interfaces and programs.

  • info@pervasive.com

    For general information about the company, marketing efforts, public relations, and other general questions.

  • investor.relations@pervasive.com

    For questions from investors.

Prev
Newsgroup 		Up
Check for Revisions 		Next
Technical Support


Technical Support

You may obtain technical support from the following Web-based support options:

    • Pervasive Knowledge Base at http://support.pervasive.com/eSupport
    • To open a support incident, http://www.pervasive.com/support/index.asp. Click on Open an Electronic Incident.
    • To report a product defect, http://www.pervasive.com/support/index.asp. Click on Report a product defect.

If you require something other than what Web-based support options provide, contact Pervasive Support by phone:

    • 800-287-4383 option 3 (the Americas)
    • CIC: +00.800.1212.3434 (Belgium, France, Germany, Italy, Luxembourg, The Netherlands, Spain, Sweden, Switzerland, and the U.K)
    • CIC: +32.0.23.37.61 (Any other European, Middle Eastern, African or Asian countries, excluding Japan)

For technical support and discussions about Pervasive products in general:

    • Visit the DevTalk forum at http://www.pervasive.com/devtalk.
    • Visit http://www.pervasive.com/company/contact/index.asp for other contact information.

Prev
E-Mail Contacts 		Up
Check for Revisions 		Next
Supplemental Information


Supplemental Information

Prev
Technical Support
Check for Revisions 		Next
Introduction to Networking


Introduction to Networking

Conceptual Information To Help You Understand Basics of Networking

This appendix discusses the following topics:

  • About this Document
  • Terminology
  • Description of a Network
  • Pervasive.SQL And Networking
  • Basic Networking Using Pervasive.SQL With Microsoft Windows Systems
  • Expanding Your Basic Network
  • Additional Reading
Prev
Supplemental Information
Check for Revisions 		Next
About this Document


About this Document

This document is a brief tutorial that outlines how to get started with a simple workgroup network and Pervasive.SQL.

Audience

This document is intended for people who want to use Pervasive.SQL data management system in conjunction with a small or home office networked environment. It will describe a simple way to network computers together and suggest methods by which you can use Pervasive.SQL in this environment.

Conventions

When you see a single word or phrase bolded, such as protocol, that means that the word is defined in non-technical terms in Terminology . If you are using an online copy of this document, you can link directly to the terminology section.

Summary of Content

  • Terminology used in this document
  • Basic components of a network
  • What is important, network-wise, to Pervasive.SQL
  • Basic networking with respect to Microsoft Windows
  • Method of troubleshooting your network
  • Ways to expand your network in the future
  • Additional reading to help you with learning about networks
Prev
Introduction to Networking 		Up
Check for Revisions 		Next
Terminology


Terminology

This section introduces you to terms used later in this tutorial.

Table 1-1
Term | Definition
network interface card | A piece of hardware that you insert into a computer for the purpose of establishing communication to other machines and the Internet.
NIC | Abbreviation for network interface card.
home/small office networking | A generalized term used to refer to hardware, software, and procedures geared towards a network configuration appropriate for use in a home or a small office.
peer-to-peer networking | A term used to refer to a network configuration in which every computer shares the resources and tasks in a network. In other words, there is no dedicated server used to process most database tasks. For purposes of Pervasive.SQL, this term is equivalent with workgroup computing. The Pervasive.SQL Workgroup database engine is designed for this type of network.
clients | Machines used to communicate with servers.
requesters | The Pervasive.SQL software used to communicate with a server. You usually install the requester on a client machine used to communicate with a server, but server and workgroup database engines installed to a machine also install the requester software to communicate with other servers if necessary.
server | A machine used as a database engine for one or more clients.
Ethernet | A type of cabling used in networking, especially in Internet-type networks.
protocol | A standardized set of instructions that enables two machines using them to communicate. For example, TCP/IP.
packets | The smallest unit of information transferred between two computers using a network protocol.
TCP/IP | The protocol that is central to the operation of the Internet.
IPX/SPX | A protocol used heavily in the past by Novell networks.
NetBUEI | A simple protocol used only in small workgroup networks.
ping | A common program used to test basic connectivity to another machine using the TCP/IP protocol.
dedicated | A machine that is not normally used as a client machine, but rather for a specialized purpose such as the primary machine for database application processing.
operating system | A low-level software system that controls the hardware of a computer such as disk drives and monitors and serves as a scheduler and resource allocator for other software such as Pervasive.SQL. Microsoft Windows, Linux, and Macintosh OS are examples of operating systems.
driver | A piece of software code that controls a device, usually hardware, that interfaces with an operating system.
machine name | An alphanumeric name given to a particular machine that identifies it uniquely on a network containing other computers and devices such as printers.
address resolution | The process by which network protocols take a machine name and, using lookup techniques, obtains a physical address by which to communicate with the target machine name.
firewall | Hardware or software used in a TCP/IP network that regulates network traffic and prevents unauthorized access attempts to the network.

Prev
About this Document 		Up
Check for Revisions 		Next
Description of a Network


Description of a Network

A network is two or more computers, each containing a network interface card (NIC), linked together via network cables.

The computers then communicate with each other by sending electronic signals over the cable. Not all computers can understand all electronic signals. Both computers must know how to interpret the signals in the same way. A set of instructions, a network protocol, defines the meanings of these signals and allows the computers to communicate using the network cable. The three network protocols supported by Pervasive.SQL are:

  • TCP/IP
  • NetBUEI
  • IPX/SPX

These protocols transfer packets of data via the NICs and network cabling between systems.

A network is part hardware and part software and both must be working correctly for communication to occur. The software includes both operating system and Pervasive.SQL configuration. This document will help you configure your software properly.

Networks usually have a device called a hub or router that is simply a box that connects the network cables from several systems to each other. Since each NIC only has one connector, hubs and routers allow all the systems to connect to each other. The cabling from each system is connected at one end to the NIC and the other to the hub or router.

A typical small- to midsized office network

Typical small to mid-sized offices generally have one of two types of networks, workgroup or client/server. Workgroup networks are systems networked together without any one dedicated system that controls the network.

Figure A-1 Simple Workgroup Network

Client/server networks have one or more systems that actually control the network and these are called servers. Servers have special operating systems designed for that purpose.

Figure A-2 Simple Server Network

Although workgroup and client-server networks generally function similarly, the servers in a client-server network control network security and access, file sharing, and other aspects of the network. These systems are dedicated to this purpose. In a workgroup network, each system controls its own security and network parameters and usually does not have the level of control that a server provides.

Pervasive.SQL offers both a Workgroup version and a Server version of its database engine. The Workgroup engine is designed for workgroup networks, but will work on networks that have Windows server systems as well. The Server version supports Windows clients to connect to Windows, NetWare, or Linux servers.

Prev
Terminology 		Up
Check for Revisions 		Next
Pervasive.SQL And Networking


Pervasive.SQL And Networking

Pervasive.SQL is designed to work with many types of networks. However, Pervasive.SQL expects certain aspects of your network to be functional and also, due to its flexibility, certain Pervasive.SQL settings must also be in alignment with your network configuration.

This section documents how to make Pervasive.SQL work with your functional network.

Checklist

  • Your computers and network hardware is setup correctly

    How to verify: See Verifying your Microsoft Windows Network Configuration

  • If you are using TCP/IP, you can use the ping command to communicate from one machine to another (TCP/IP only)

    How to verify: See Ping

  • Your Supported Protocols configuration parameter is set to the protocols used by your organization, and all workgroup computers on that network share this same setting

    How to verify: See Supported Protocols

  • If you are using the NetBIOS or NetBUEI protocols, your NetBIOS Port configuration parameter is the same on all workgroup machines

    How to verify: See NetBIOS Port

Pervasive.SQL Networking Settings

Pervasive.SQL has some configuration parameters that can affect your ability to communicate successfully with other machines. These parameters are not related to the operating system network settings discussed in Verifying your Microsoft Windows Network Configuration .

This section discusses those settings and provides links to more information in other sections of the documentation for Pervasive.SQL.

Supported Protocols

This setting controls the protocols that Pervasive.SQL uses to communicate with other machines. If you have a workgroup configuration with five machines, you would want all of them to have the same settings so that communication succeeds.

NetBIOS Port

This setting is only important if you are using the NetBUEI protocol to communicate in a workgroup environment. By default, Pervasive.SQL uses port 66 to communicate. If no one on your network has altered the default setting, then Pervasive.SQL should be able to communicate using this protocol.

Auto Reconnect

This setting controls how Pervasive.SQL requesters will attempt to reconnect when a network outage occurs. This setting is enabled by default.

Where to Get More Information

For more information on setting up protocols and configuring other settings for the Workgroup engine, see Network Settings .

For more information about configuration settings in general, see Advanced Operations Guide.

Prev
Description of a Network 		Up
Check for Revisions 		Next
Basic Networking Using Pervasive.SQL With Microsoft Windows Systems


Basic Networking Using Pervasive.SQL With Microsoft Windows Systems

This section documents how to set up your Microsoft Windows network to work properly with Pervasive.SQL. This section contains the following topics:

  • How to Install and Configure Networking Components
  • Verifying your Microsoft Windows Network Configuration
  • Setting Up Protocols on Windows
  • Basic File Sharing Setup
  • Microsoft Windows Networks that Include Novell Servers

How to Install and Configure Networking Components

We will assume that you have the proper network adapters (NICs) installed in the computers that you are planning to use with Pervasive.SQL, and that the network wiring is in place and functioning properly. If you need help installing this system hardware and ensuring that it is working properly, here are a few options:

  • If you would rather not do it yourself, contact a local computer store and ask for a consultant to help set up your computer network. They may even offer these services through the store.
  • If you would like to perform this task yourself, visit your local computer store and buy an Ethernet adapter (NIC) for each computer, an Ethernet hub, and enough Ethernet cable to hook them to the hub. The instructions that come with the network cards and hub will help you get the hardware functioning properly. You can probably find some additional help on the website of your operating system vendor.

Verifying your Microsoft Windows Network Configuration

This section outlines how to configure the software aspects of networking for Microsoft Windows operating system.

What to Expect

When you install Windows, the default networking configuration may vary depending on your system hardware and other factors. This variability is compounded by the fact that most people receive a machine that has had Windows already installed at the factory. In many cases, a network protocol has already been installed. If you have a network card installed, the driver for the network card should also be installed.

Today's most popular network protocol, called TCP/IP, is the preferred protocol for Pervasive.SQL. TCP/IP has the advantage of being the best performing protocol for Pervasive.SQL, but it also is the most difficult for novices to configure. Still, with the assistance of this information, you should find the configuration process straightforward. If you just don't feel comfortable configuring TCP/IP, you can use NetBUEI as a more simple alternative for small workgroup networks. See Basic Setup of NetBEUI for more information.

Viewing your Windows Network Properties

You should first view your Windows network properties to make sure that you have:

  • An installed network card
  • At least one installed protocol such as TCP/IP

Following are procedures to test whether the preceding items are true.

To display your Windows network properties

  1. From the Start menu, select Settings 4 Control Panel

Windows 98 and Windows NT

  2. Double-click Network.

Windows ME, Windows 2000, Windows XP

  2. Double-click Network and Dial-up Connections.
  3. Double-click Local Area Connection.
  4. Click Properties.

You should see a screen similar to Figure A-3 .

Figure A-3 Local Area Network Properties Sheet

To verify that you have a network card installed properly

  1. View your Network properties as described in To display your Windows network properties
  2. Look near the top of the Network Properties Sheet (Figure A-3). If your Connect using field (Figure A-4) is blank, that means the NIC is not properly installed.

    Recovery: You will need to contact your hardware vendor for help in installing a network adaptor.

Figure A-4 Network Properties - Installed Network Card

  3. Click Cancel to close the properties sheet.

Setting Up Protocols on Windows

This section outlines the procedures for checking the status of certain protocols on Windows machines.

Basic Setup of TCP/IP

TCP/IP is a protocol that uses a 4-part number, similar in function to a postal address, to identify each computer on the network. No two address numbers are permitted to be the same. The numbers in each portion of the address can range from 0-255, and the four parts are separated by periods. For example, a TCP/IP address like 167.111.15.4 is valid since it contains all 4 parts separated by periods and each part falls within the 0-255 range. A TCP/IP address of 167.256.15.4 is not valid since one of the numbers exceeds the 255 limit.

Additionally, a special TCP/IP address called a subnet mask must be entered on each system. This identifies the network itself with a unique address and is the same address for all systems on the network. The subnet mask address in simple networks is usually 255.255.0.0. The technical details of subnet masks are quite complex and outside the scope of this document. However, if you desire to learn more about TCP/IP and subnet masks, there are many books on the subject available at your favorite book store.

To enable TCP/IP on a Windows machine

  1. View your Network properties as described in To display your Windows network properties
  2. If TCP/IP is in the list, it is already enabled so you should click Cancel. If TCP/IP is not in the list, continue with this procedure.
  3. Click Add or Install.
  4. Select Protocol from the list that is displayed and click Add.
  5. Select Microsoft from the list on the left, and select TCP/IP from the list on the right
  6. Click OK to install the protocol.
  7. If you do not have two lists, select TCP/IP from the single list displayed.

Note
You may need your Windows installation CD.

Assigning TCP/IP Addresses

If you are running Windows NT, you must manually assign your TCP/IP addresses. All other Windows systems (98, 2000, ME, XP) should automatically assign your TCP/IP address. To verify this, restart the systems after installing TCP/IP and open Network Neighborhood located on the desktop of one of the systems. If the other systems on the network show up, then TCP/IP is properly installed and addresses are assigned. If this is the case, you can skip the next section on manually assigning TCP/IP addresses.

A set of TCP/IP addresses has been reserved for private networks that are not connected to the Internet. The range of these addresses is 169.254.0.1 through 169.254.254.254.

To manually assign TCP/IP addresses

  1. View your Network properties as described in To display your Windows network properties .
  2. Double-click TCP/IP in the list.
  3. A TCP/IP properties sheet similar to Figure A-5 should display.

Figure A-5 TCP/IP Protocol Properties Sheet

  4. In the IP Address field, enter 169.254.0.1 for the first system on your network.
  5. Enter 255.255.0.0 in the Subnet mask field.
  6. Repeat these steps for each computer on your network and increase the last number of the TCP/IP address by one each time.

    The second system would be 169.254.0.2, the 3rd would be 169.254.0.3, and so on. If you have more than 254 systems on your Network, once you get to 169.254.0.254, the next system should be 169.254.1.1 and the process repeats from there.

    Two things to keep in mind are that the first two numbers in the TCP/IP addresses for all systems must be 169 and 254 and all the systems must have the same Subnet mask of 255.255.0.0.

Hosts file

Some operating systems use a file called Hosts to resolve, or map, TCP/IP addresses to system machine names. The hosts file is installed on all Windows operating systems and contains instructions on how to set up the file to resolve the addresses. If after you install and configure TCP/IP your systems cannot see each other, try opening the Hosts file and following the instructions in that file for adding your system information. The Hosts file content looks similar to the following:

# Copyright (c) 1993-1999 Microsoft Corp.
#
# This is a sample HOSTS file used by Microsoft TCP/IP
# for Windows.
#
# This file contains the mappings of IP addresses to
# host names. Each
# entry should be kept on an individual line.
# The IP address should
# be placed in the first column followed by the
# corresponding host name.
# The IP address and the host name should be separated
# by at least one space.
#
# Additionally, comments (such as these) may be
# inserted on individual
# lines or following the machine name denoted
# by a '#' symbol.
#
# For example:
#
#   102.54.94.97     rhino.acme.com
#         source server
#   38.25.63.10     x.acme.com
#         x client host

127.0.0.1       localhost
172.16.0.99     auspvsw1

Each system TCP/IP address is listed followed by the system name.

There are many other aspects of TCP/IP such as gateways, DNS servers, DHCP servers, and more. These are for complex networks and outside the scope of this text.

The above information is a very abbreviated summary of TCP/IP networking. If you are a small-office user working with Pervasive.SQL, this information may be all you need to know. For those with the desire or need to know more about TCP/IP networking, see Additional Reading .

Basic Setup of NetBEUI

NetBEUI is an easy-to-use protocol designed for workgroup networks. However, NetBEUI cannot be used for Internet access, or true client-server networking. If you have plans to expand your network beyond the workgroup, you may want to reconsider the decision to use the NetBEUI protocol.

If you are setting up a workgroup network and are not comfortable with the settings associated with TCP/IP, NetBEUI may be ideal.

To enable NetBEUI on a Windows machine

  1. View your Network properties as described in To display your Windows network properties .
  2. Click Add or Install.
  3. Select Protocol from the list that is displayed and click Add.
  4. Select Microsoft from the list on the left, and select NetBEUI from the list on the right.

    On Windows NT, 2000, and XP systems, there may be a listing for a NetBIOS protocol instead of NetBEUI. If this is the case, select the NetBIOS protocol.

  5. Click OK to install the protocol.
  6. If you do not have two lists, select NetBEUI from the single list displayed.

Note
The NetBEUI protocol cannot be used with Pervasive.SQL Server database engines; only the Workgroup database engine supports the NetBEUI protocol.

NetBEUI does not need any additional configuration steps.

The preceding information is an abbreviated summary of NetBEUI networking. If you are a small-office user working with Pervasive.SQL, this information may be all you need to know. For those with the desire or need to know more about NetBEUI networking, not much formal documentation exists since this protocol was never standardized. However, an Internet search on NetBEUI should yield a few informative articles and papers.

Basic File Sharing Setup

If you are working with a newly installed computer, or have never shared files between computers on a network, you will likely need to enable file sharing on each Windows computer.

Why to Use File Sharing

File sharing allows others to access selected folders on your computer over the network, and it is not a feature that Windows enables by default. You might use file sharing to access some database files used on another machine in your network since most workgroup networks have a high level of trust among its members. For example, a small network probably includes members of your team.

To enable file sharing on Windows 98/ME

  1. View your Network properties as described in To display your Windows network properties .
  2. Click the File and Print Sharing button at the bottom of the window and make sure that I want to be able to give others access to my files is checked.
  3. Click OK to close both windows.

Note
You will probably be asked for your Windows CD and have to restart to complete the setup.

To enable file sharing on Windows NT, 2000, XP

  1. View your Network properties as described in To display your Windows network properties .
  2. Click Add or Install.
  3. Select Service and click Add.
  4. Select the File and Print sharing for Microsoft networks service.

Note
If your system is a client to a NetWare server, you should select File and Print Sharing for NetWare networks in this step.

  5. Click OK.

Microsoft Windows Networks that Include Novell Servers

If you have Novell NetWare servers as part of your network, you might have a third protocol called IPX/SPX. This protocol was designed with NetWare in mind, so Windows-only networks most likely will not include this protocol. If your network does include Novell servers, this section will show you how to set up your IPX/SPX protocol.

If you do not have any Novell servers on your network, you can skip to Methods of Troubleshooting Your Network .

Basic Setup of IPX/SPX

Although this document is focused on workgroup networking, this section contains a brief overview of the IPX/SPX server protocol and how to connect Pervasive.SQL clients to it.

IPX/SPX is a protocol that was primarily designed for earlier versions of NetWare servers. In order for your Pervasive.SQL Windows clients to connect to these NetWare servers, IPX/SPX must be installed on the Windows clients. IPX/SPX is not recommended for use in Windows server networks and cannot be used in workgroup networks since it provides no method for address resolution.

To set up IPX/SPX on your machine

  1. View your Network properties as described in To display your Windows network properties .
  2. If IPX/SPX is not in the list, click Add or Install.
  3. Select Protocol from the list that is displayed click Add.
  4. Select Microsoft from the list on the left, and select IPX/SPX from the list on the right
  5. Click OK to install the protocol.
  6. If you do not have two lists, select IPX/SPX from the single list displayed.
  7. After IPX/SPX is installed and shows up in your network properties:

    Windows 9.x systems: Double click the entry for IPX/SPX and select Enable NetBIOS.

    On other Windows operating systems, you will need to add the NWLink NetBIOS protocol in the same manner as you added IPX/SPX. Pervasive.SQL requires NetBIOS support when using the IPX/SPX protocol.

The preceding information is an abbreviated summary of IPX/SPX networking. If you are a small-office user working with Pervasive.SQL, this information may be all you need to know. For those who wish to know more about IPX/SPX networking, see Additional Reading .

Prev
Pervasive.SQL And Networking 		Up
Check for Revisions 		Next
Methods of Troubleshooting Your Network


Methods of Troubleshooting Your Network

This section outlines testing techniques to troubleshoot your network.

Ping

Ping is a commonly used program in Windows and UNIX operating systems to test your connectivity to another machine. Ping should be your first test when troubleshooting a problem with Pervasive.SQL to another machine and you are using the TCP/IP protocol.

Note
Ping is only for TCP/IP and it does not work with the IPX/SPX or NetBEUI protocols.

A successful Ping does not necessarily mean that Pervasive.SQL is configured correctly. However, if you cannot Ping the remote server, then with all certainty Pervasive.SQL will not successfully connect either. This is why it is a good test to run before attempting to troubleshoot a problem with your Pervasive.SQL configuration.

To Ping another machine in Windows

  1. From the Start menu, select Run
  2. Enter the following at the prompt:

    ping machinename

    where machinename is the identifying name given to a machine under Windows network properties. See machine name for more information.

  3. If you are communicating, you should see a response similar to this:

Figure A-6 Successful Ping of Remote Machine

  4. If there is no communication, you should see an error message such as Unknown Host or Request Timed Out.

    Recovery:

    • Check your network settings as described in Verifying your Microsoft Windows Network Configuration .
    • You may need to add entries to your Hosts file in order to ping using a machine name. See Hosts file for more information.
    • Use Pervasive System Analyzer (PSA) to obtain more information about the root cause of the failure. See Pervasive System Analyzer (PSA) for more information on PSA.
    • Check with the administrator of your network or the remote machine to see if a firewall may be blocking access.

Pervasive System Analyzer (PSA)

Pervasive System Analyzer (PSA) is a utility included with your Pervasive.SQL Workgroup database engine that troubleshoots a number of things about your system, including network connectivity to another machine.

To start PSA

  • Click Start, and select Programs 4 Pervasive System Analyzer.

Documentation for PSA

The PSA utility is documented fully in Pervasive.SQL User's Guide. Please see Pervasive System Analyzer (PSA) in that manual for complete information. You can also start PSA and click Help for the same information in online format.

Prev
Basic Networking Using Pervasive.SQL With Microsoft Windows Systems 		Up
Check for Revisions 		Next
Expanding Your Basic Network


Expanding Your Basic Network

This section looks at ways to augment the power of your network in the future.

Server Operating Systems

Server networking and security can be very complex topics and are outside the scope of this text. However, the following general guidelines are provided for informational purposes:

  • User must have access rights to the server and database directories
  • Clients must be using the same network protocol as the server to connect (note that clients can use more than one protocol at a time)
  • Pervasive provides a tool called Pervasive System Analyzer (PSA) that can help troubleshoot some network issues. You can download PSA at http://www.pervasive.com.
  • Pervasive supports Windows, NetWare, and Linux servers as described in your version's documentation.

Additional information on server networking can be found at the website for your server operating system.

Prev
Methods of Troubleshooting Your Network 		Up
Check for Revisions 		Next
Additional Reading


Additional Reading

This section contains links to more information.

Networking in General

  • See O'Reilly Press for a number of books on networking and system administration (http://sysadmin.oreilly.com).

TCP/IP Protocol

  • TCP/IP Network Administration second edition, by Craig Hunt from O'Reilly Press.

IPX/SPX

  • Novell's Guide to LAN/WAN Analysis: IPX/SPX from Hungry Minds, ISBN: 0764545086.

NetBUEI

  • This protocol was never standardized, so no formal specifications exist. However, you can search via the Internet to find some topics on this protocol.

Pervasive.SQL Topics in Networking

  • http://www.pervasive.com/library (run a search on "network" at this address)
  • Advanced Operations Guide contains a chapter that explains much about the Workgroup engine. See Workgroup Engine in Depth in that manual for more information.

Prev
Expanding Your Basic Network 		Up
Check for Revisions 		Next