Pervasive logo

Prev User's Guide Next

Frequently Asked Questions

This section answers some of the questions that customers ask most frequently. A list of the questions is provided below:

Installation
Security
Documentation
User Counts
Networking
Difficulty Accessing Data
ODBC and DDFs
Upgrading from Btrieve 6.15
Upgrading and Migration
Miscellaneous

Installation

Will I lose my data files if I uninstall my existing version of the product, or install a new version?

When you uninstall Pervasive.SQL or install a new version of Pervasive.SQL, your data files and DDFs are never affected. Even when Pervasive System Analyzer archives Pervasive.SQL files, or even if you have your data files in the same directory as Pervasive.SQL files, your data files are not affected.

What type of client install should I do-typical, custom, or network?

If you are not sure, always select typical. This option performs a standardized installation, which makes it easier to troubleshoot if problems occur.

How can I be sure what service pack level of client I am running?

If you are using Pervasive.SQL V8, start Monitor or Maintenance, choose Help4About from the menu, and check the Build Level.

Is Pervasive.SQL supported on a Terminal Server?

Support for both the Server and Workgroup engines on Terminal Server has been available since Pervasive.SQL 2000i, SP 4. Pervasive.SQL 2000i, SP 3 provided support for the Server engine. Pervasive.SQL 2000i, SP 2 provided supports only for the client software.

Can I install Pervasive.SQL in a Failover environment? or

Can I install Pervasive.SQL in a Clustering environment?

Pervasive.SQL 2000i SP3 or later can be installed into a Windows 2000 Advanced Server Cluster or into a Novell NetWare 5.1 Cluster. Earlier versions of Pervasive.SQL are not supported in a Failover or Clustered environment. Linux clusters are not supported at this time.

Can I install Pervasive.SQL in a Load Balancing environment?

That is not supported at this time.

Can I install Pervasive.SQL on a server running Btrieve v6.x or earlier?

No, you cannot run Pervasive.SQL and Btrieve 6.x on the same computer at the same time.

I installed Pervasive.SQL on my Netware 5.x server and it still says I am running the older version. What's wrong?

With Netware 5.x, you have to shut down the server and reboot for the new version of the database engine to be loaded into memory.

How do I keep my Workgroup Engine from starting up automatically when I reboot?

You must remove it from the Startup group under Start4Programs.

On Windows 98, the contents of this group are located at:
c:\windows\start menu\programs\startup.

On Windows NT, the contents of this group are located at:
c:\winnt\profiles\user\start menu\programs\startup

On Windows 2000, the contents of this group are located at:
c:\Documents and Settings\user\start menu\programs\startup

On Windows NT/2000, user can be replaced by "All Users" or any user, as appropriate.

Security

Your security model is confusing. When do I login using an operating system user and password, and when do I login using a database user and password?

This may seem confusing at first, but in fact there is only one rule: use a database login only after you have already successfully connected to the server and are attempting to access a database directly. Up until this point, you should use an operating system login.

For example, if you run Monitor or Configuration to work with a remote server engine, you are prompted for a password. In both cases, you must supply a user name and password for an operating system account that has administrative permissions on the remote system, or an account that is a member of Pervasive_Admin. This applies also when you are creating a new database.

Once you start to work with the data itself, then you must supply a database user and password, if prompted. If database security is turned off, then you would never need a database user name or password. In this case, you would only need an operating system user and password to perform administrative tasks, as noted in the preceding paragraph.

Why do I get a "log in failed" message when I have a Pervasive_Admin group defined or I have administrator rights?

The settings for the Pervasive.SQL services can affect whether or not you have permission to log in to the machine where the database engine is running. The settings apply whether or not you use a Pervasive_Admin group. If you change the Log on as setting for a Pervasive.SQL service to This account, you must change the user rights policy Act as part of the operating system for the account. Otherwise, remote log in fails.

For example, both the Monitoring utility and the Configuration utility require that you log in to the operating system on the machine where the database engine is running. You will receive a message that log in failed if the account specified for This account cannot act as part of the operating system.

Note that even the Administrator account requires that you set the user rights policy for Act as part of the operating system.

See Services Settings and Log In Authority for a complete discussion and the steps to change the user rights policy.

Documentation

Why does my computer have a different format of online documentation than my co-worker's computer? We both installed the same software.

Starting with Pervasive.SQL 2000i Service Pack 3, the type of online documentation that is installed depends on your system. Computers that support Microsoft HTML Help, also called Windows 98 Help, automatically receive that format of online documentation during the Pervasive.SQL installation. Computers that cannot support Microsoft HTML Help automatically receive Windows 95 Help files. The actual content within each format is identical.

User Counts

How do I apply a User Count Upgrade?

Refer to the tasks discussed in the chapter License Administrator .

How does the Workgroup engine keep track of how many people are accessing the data? If people access the data with two engines at the same time, what happens?

The Workgroup engine keeps track of users just as the Server engine does. That is, each combination of a set of requesters and an application creates a unique client ID. Licenses are tracked per computer based on the unique ID for the network card. Only one engine is ever permitted to access the files at a time. The second engine to try to open the files gets locked out, because the engines open the data files in exclusive mode (non-file sharing) so that corruption cannot occur.

Does the Workgroup engine use concurrent or per-seat licensing?

Concurrent. Refer to User Count .

Aside from licensing, is there a limit to how many users can access a Workgroup engine simultaneously?

The Workgroup engine architecture is basically the same as the Server engine. The Workgroup engine ships with a five user license. For user count licenses higher than five, choose the Server engine for your organization.

Networking

How do I know which protocol I am using for communication? I can see other systems in Network Neighborhood but I can't get to my data.

From the Start menu of any Windows computer with the database client installed, choose Programs4Pervasive System Analyzer. In the Welcome screen that appears, click Next. In the following screen, check the box Test Network Communications and make sure all the other boxes are not checked. Click Next. In the following screen, cancel the selected protocols that you do not want to test. Click Browse to select the drive that you have mapped to the installation directory (C:\PVSW by default) on the server. You must have a mapped drive; UNC names are not supported. Click Next to run the network tests. The results window tells you if there are any significant problems with your networking.

Difficulty Accessing Data

I upgraded from Btrieve v6.x or earlier to Pervasive.SQL V8. Now I get error messages telling me that a file is inaccessible when everybody else can get to it. What's wrong?

Use Pervasive System Analyzer to be sure that all components from previous versions of Btrieve or Pervasive.SQL have been archived. Then, make sure your configuration settings are correct. Find the file pvsw.log and check for error messages indicating a status code 8505 or 8517. These status codes indicate that attempts were made to use a local Workgroup engine to read the data files. From the Start menu, choose Programs4Pervasive.SQL V84Control Center. Double-click Pervasive.SQL Engines. Double-click the icon representing your computer. Double-click Configuration. Double-click Client. Click Access. In the right-hand pane, make sure the following settings are set: Use Local MicroKernel Engine is "Off," and Use Remote MicroKernel Engine is "On."

I have files sitting on the server that are shared and yet Pervasive.SQL cannot read them. What's wrong?

How are the files shared? Pervasive does not support mapping a drive letter using the Map Root under Novell, or using Redirected mapping under Microsoft, or using the hidden Admin share (C$) under Windows NT/2000.

Make sure that users have appropriate operating system login credentials to access the file server.

Run Pervasive System Analyzer and choose the Network Communications Test to be sure that you have proper connectivity.

I am using SQL queries to create a definition for an old table. The resulting record size is off. Why?

Starting with Pervasive.SQL 2000, fields that allow null values have an additional byte defined at the start of the field. This byte is the null indicator byte. You can work around this in one of two ways:

If you are using SQL statements to create a new table definition, enter the statement SET TRUENULLCREATE=OFF. For the remainder of your current session, any tables that you create will use the old record structure without the extra byte for each nullable column.

If you do not wish to use SQL statements, you can get the field sizes to align properly by creating all columns as not nullable.

I want to convert my data file version from 8 back to file format version 7, 6 or 5. How do I do this?

If the files you wish to convert are serviced by a remote Server or Workgroup engine, you must have Administrator permissions on the remote system in order to perform these tasks. You must also have a network drive mapped to the remote data files.

Using Pervasive Control Center, double-click the icon that represents the server where the data files are located. Double-click Configuration for that server. Double-click Server then click Compatibility. Click on Create File Version and set the value to the file version to which you want to convert. From the menu, choose Edit4Apply. Restart the database engine. These changes result in new files created to be in the version selected.

From the Start menu, choose Programs4Pervasive.SQL V84Other Utilities4Maintenance to start Btrieve Maintenance Utility. Within this program, choose Options4File Information Editor. Click Load Information and choose the data file that you want to convert. Click Create and specify the name of the new, empty data file you want to create with the older version format. Click OK to create the file. Close the File Information Editor window, but do not exit Btrieve Maintenance Utility.

From the menu, select Data4Copy. Enter the name of the source data file and the name of the target data file (your newly created file with the older version file format). Click Execute to copy the records into the older version file. After the copying has finished, if you need the new data file to have the same name as it did previously, save your original data file with a different name, then save your new file using the original file name.

ODBC and DDFs

How can I tell if I can use ODBC to access my data files?

There are several ways to find out. First, look for .DDF files where the data files are located. If you see them, then most likely you can access the database using ODBC. Because it is possible to have DDF files located in a different directory, you should also use PCC to determine whether a database has been created for the data files you want to access. Finally, you can ask your application vendor whether their application uses ODBC to access the data files.

How can a hard-coded filepath in a DDF be changed?

Using PCC, right click on the table and choose Tasks4Edit table design. Click on the Statistics tab. Locate the parameter Table Location and change the value to the file path you wish to use. From the menu, choose File4Save.

It may appear that the path has not changed. To confirm the change, open the X$File system table and look at the Xf$Loc field for the given user table. If you cannot see the system tables in PCC, click on the View menu and choose Show system tables.

You can also use the ALTER TABLE USING statement in SQL to change the data file used by a particular table. Refer to SQL Engine Reference for further information.

I have DDFs from Scalable SQL 3.01. Are they compatible with Pervasive.SQL V8?

DDFs from Scalable SQL 3.01 are not compatible with Pervasive.SQL V8. You can use the CNVDDF utility provided on the Pervasive web site to convert the older DDFs to the new format. CNVDDF is a DOS utility that enables you to convert a database dictionary from Scalable SQL 3.01 to Pervasive.SQL V8 format. To run the utility, make sure that either the Btrieve DOS Box or another DOS requester is loaded on the client workstation.

The utility is located at:

http://www.pervasive.com/support/toolbox.asp

Note
Converting database dictionary files in the CNVDDF utility does not modify any non-system table Btrieve files; it only modifies FILE.DDF, FIELD.DDF, and INDEX.DDF. It is recommended that you back up the original files to another directory before making any changes to the dictionary files using CNVDDF. This will enable you to restore your original DDFs.

What is the best way to ensure that my data dictionaries (DDFs) are safe?

Always keep a backup copy of your DDFs. Anytime you make changes to the runtime DDFs, be sure to make a backup copy of the DDFs before making changes. If you are turning on database security for the first time, you should make a backup copy of the dictionaries without security, and a backup copy with security.

How can I tell whether I have non-standard DDFs?

If you can edit your DDFs with a Btrieve utility, it means that you do not have standard dictionary files. A standard dictionary file does not permit direct Btrieve access. This lock out is a safety feature that ensures only the SRDE can write to the dictionary. DDFs are very special files that must remain synchronized with each other and with the data files at all times.

Standard dictionaries do not have case sensitive table names or field names. That is, the column definitions for column Xf$Name in file.ddf and column Xe$Name in field.ddf have the Case flag set, meaning the values are case insensitive.

DDFs are Btrieve files and thus can be opened and viewed (not updated) using the Function Executor. This is one way to confirm the contents of file.ddf or field.ddf.

On some non-standard dictionaries, the DDFs file.ddf, field.ddf, and/or index.ddf do not exist. Such dictionaries do not work with our products. For example, if you see a file called x$file.ddf, instead of file.ddf, you can assume your DDFs are non-standard.

Non-standard DDFs are unlikely to work properly with Pervasive Control Center or the relational engine.

Can I mix and match DDFs from different databases?

A complete set of DDF files must be considered a unit. No DDF file from one database may be intermixed with DDFs from a different database.

What happened to DDF Builder and DDF Sniffer?

DDF Sniffer and DDF Builder were added to the Pervasive product line with the acquisition of Smithware in 1998. Neither DDF Sniffer nor DDF Builder are available anymore. They were replaced by DDF Ease, which was part of the Pervasive.SQL 7 database engine. DDF Ease has since been replaced by Pervasive Control Center in Pervasive.SQL V8.

DDF Sniffer and DDF Builder used the Btrieve API to manipulate DDFs, which was less desirable than doing it through the native relational interface of Pervasive.SQL. These products contributed to issues that were difficult to isolate and fix.

Does Pervasive Control Center have the same functions as DDF Sniffer? Namely, can PCC read a Btrieve data file without DDFs and analyze the file to help me build DDFs?

Yes, it does in general, but it lacks some of the automation features offered by DDF Sniffer, such as the ability to recommend data types to use for non-indexed fields. However, PCC avoids many of the problems that DDF Sniffer and DDF Builder encountered in trying to create and maintain DDFs via the Btrieve API rather than through the relational engine. The result is that you probably need to know a bit more about databases and data types than you would with DDF Sniffer, but you will wind up with fewer problems in the long run.

For more information, see the question and answer immediately above.

How do I set up ODBC on a NetWare server so that I can perform relational operations?

Pervasive.SQL includes an ODBC manager for NetWare. All you need to do is use PCC to create a new database on the NetWare server, then create a client DSN on the client to make the remote database available to client applications.

You must have administrative permissions on the NetWare server to perform these tasks. Here are the steps in more detail:

  1. Load the relational module on the NetWare server by issuing the command mgrstart.
  2. At a Windows computer with Pervasive.SQL client installed, start PCC by choosing Start4Programs4Pervasive.SQL V84Control Center. Double-click Pervasive.SQL Engines. If you do not see the NetWare server name listed, then right-click and choose Register New Engine. In the window that appears, type in or browse to the NetWare server where the database engine is located. Click OK.
  3. After the server icon is displayed in PCC, double-click on the icon that represents the server. Then double-click on the Databases folder. If you do not see the database you want to connect to, right-click on the Databases folder and choose New Database.
  4. In the screen that appears, choose Engine interface and enter a NetWare user name and password with administrative permissions on the NetWare server. Click Next.
  5. In the following screen, enter the name of the database and the directory where the data files are or will be located. This directory cannot be a mapped drive or relative to the client. It must be a full path name on the server, as if you were seated at the server console.

    If you want to make existing DDFs and data files available for remote access, check Use Advanced Settings. If you are creating a brand new database from scratch, do not check this box.

  6. Follow the prompts provided. For detailed procedures and options, see Chapter 2 of this book and/or see Advanced Operations Guide.

After you have created the Engine DSN on the server, you can access the database using PCC. If you want to access the database using ODBC-based applications, then you need to use ODBC Administrator to create a local client DSN on your workstation. You can do so by choosing Start4Programs4Pervasive.SQL V84Other Utilities4ODBC Administrator. In ODBC Administrator, click the System tab, then click Add. In the window that appears, select Pervasive ODBC Client Interface and click Finish. In the following window, type in a name for the local DSN, and enter the server name. Click Get DSN List. In the box labeled Data Source Name, choose the DSN that you created on the NetWare server. Click OK.

You can now access the database on the NetWare server by connecting to the local client DSN you just created.

I have two similar Btrieve files, and I created a DDF for the first one. Since they are similar, can I use the same DDF on the second Btrieve file?

The answer depends on how similar the files are. If the two files differ only in the number of records, you can use the same DDF file. If there are any differences at all in the number, order, names, or types of fields or indexes, you cannot use the same DDF. In other words, you can only use the same DDF if the record structure of the two files is identical.

I have owner names set on my Btrieve files. After I created a DSN, I cannot open the files using ODBC. What's wrong?

If Btrieve files have owner names on them, you must use database security for ODBC access. Turn on database security in PCC by following these steps: right-click on the database name, choose Properties, and click on the Security tab. In the screen that appears, enter and confirm the master user password.

Caution
Do not forget the Master user password. You cannot turn off security or perform administrative tasks within the database without it. You may want to make a backup copy of your DDFs before turning security on, in case you forget the password.

Next, you must grant the Master user access to the data files that have owner names defined. You can grant the access by issuing this SQL statement for each table that has an owner name: 

GRANT ALL ON my_table 'ownername' TO Master

When you enter the statement, substitute the actual name of your table and the appropriate owner name for that table, as indicated above. Remember that each data file corresponds to an ODBC table. If you don't know which table corresponds to which data file, use PCC to find out: right-click on the table in PCC, and choose Tasks4Edit Table Design. In the Table Designer, click on the Statistics tab. The Table Location field shows you the file that is referenced by that table definition.

If security is important, then you must create users and assign permissions for all users expected to access the database. You do this by using CREATE USER, CREATE GROUP, and GRANT statements in SQL. You can also use the Users and Groups feature of PCC.

If security is not important to you, you can avoid creating many users and assigning privileges by granting access to PUBLIC, which means anyone on your network can access the data. You can use this statement: 

GRANT ALL ON my_table 'ownername' TO PUBLIC

Is there a client side requester for the SRDE?

There is no DOS requester support for SQL applications, but the Pervasive.SQL client software for Windows includes ODBC client components allowing you to connect to a remote SRDE server engine.

Is ODBC the only method of access for Pervasive.SQL?

Definitely not! In addition to ODBC and the time-tested Btrieve API, you can also develop applications using our OLE DB provider, our JDBC driver, our pure Java interface, or our ActiveX controls.

Is there a single database file housing all the data, data definitions, stored procedures, security, table relationships, and so on as in some other products?

No. Pervasive.SQL stores data in separate files, one file per relational table definition. The meta data, such as data definitions, user/group definitions, and so on, are stored in a set of DDF files, where each file ends in the extension ".ddf."

Does the SQL engine (SRDE) have scheduler capabilities to run stored procedures or other types of scripts designed to access and affect data?

The SRDE does not have a scheduler.

Upgrading from Btrieve 6.15

After I upgrade the database engine on NetWare, is the SQL engine (SRDE) going to interpret Btrieve calls, or is it necessary to continue running the Btrieve.nlm?

Pervasive.SQL includes a new version of Btrieve.nlm. It also includes a new module named nwmkde.nlm. In the new architecture, Btrieve.nlm is a stub that calls nwmkde.nlm to perform operations. You must have both of these modules running.

On NetWare, will the 6.15 Btrieve NLM interface with the new MicroKernel engine, or will the 8.x version of Btrieve NLM have to be loaded to continue accessing the current Btrieve files?

You cannot use the 6.15 version of Btrieve.NLM with Pervasive.SQL. You must load all NLMs from the same product version.

My current files are in a 5.x format. Will they have to be converted to be accessed by the SQL engine (SRDE)?

The SRDE accesses 5.x format files through the MicroKernel. No file conversion is needed. You must convert the files to 8.x format to take advantage of new features offered by the 8.x MicroKernel. However, the SRDE requires DDFs for your data files. If you do not have DDFs, in some cases you may be required to modify your file indexes before you can create valid DDFs. The steps required to create DDFs for Btrieve files are explained in Advanced Operations Guide, Chapter 13.

I have DDF files today that were used by a product called Xtrieve. They are in a 4.x file format. Can they be used by the SQL engine or will they have to be converted?

They must be converted to the Pervasive.SQL DDF format using the tool DDFCNV. For more information about this tool, see I have DDFs from Scalable SQL 3.01. Are they compatible with Pervasive.SQL V8? .

Is there a tool that replaces Xtrieve?

There is no direct replacement, but you should consider using Crystal Reports for Btrieve as an excellent upgrade from Xtrieve for reporting on and querying Btrieve data.

I expect to continue using my old applications and files and phase in new applications to access the same files through the SQL engine (SRDE). Is this a false expectation?

Generally speaking, no. Pervasive.SQL is designed to allow concurrent access between SRDE applications and Btrieve applications. If you are currently using Btrieve without ODBC, you may need to make some changes to the indexes on your files before you can create DDFs that provide SRDE access to the data. The steps required to create DDFs for Btrieve files are explained in Advanced Operations Guide, Chapter 13.

Upgrading and Migration

How can I migrate a Btrieve database from NetWare to Windows NT/2000 or vice versa?

Shut down the Btrieve engine on the source computer and copy all the database files from the source computer to the target computer.

Install Pervasive.SQL V8 Server engine on the target computer.

Create a new database using existing DDFs and data files.

Share the server resource as appropriate.

Win32 Clients: No change

DOS Clients: If moving to Windows NT, replace BREQUEST with BREQNT or BREQTCP. If moving to NetWare, replace BREQNT or BREQTCP with BREQUEST. See also the readdos.txt file installed with the database engine.

When I create a table using an existing Btrieve file, the wizard displays fewer columns than there are in the Btrieve file. What's wrong?

Btrieve files contain a limited amount of information about the structure of the file. The table creation wizard can figure out some field definitions using the indexes, but after the indexes are exhausted, data segments may remain that contain more than one actual field. The wizard has no way of interpreting the contents. You must use your detailed knowledge of the record structure to split out these fields and build a table definition that matches all the fields in the record.

The procedure for this task is provided in Advanced Operations Guide.

Where can I find information on migration from earlier product versions to Pervasive.SQL V8? Where can I find migration and compatibility information?

Getting Started with Pervasive.SQL contains an entire chapter that provides detailed instructions on how to upgrade.

If your application uses Scalable SQL or ODBC, then you should review the Application Migration Guide available on the web site:

http://www.pervasive.com/library/index.asp?_shownode=MIG

Miscellaneous

I dumped Btrieve records to a file and now I can't read the file. What happened?

If you use the Btrieve Maintenance Utility to save/dump the records, the resulting file contains the binary image of each record. Unless the record consists entirely of character data, it may not be readable to the human eye.

The only way that Pervasive.SQL can dump a record in ASCII readable format, is by reading the DDFs to get a description of the total contents of the record. Btrieve only has the record length, the data type of indexes and length of the indexes. Btrieve does not have information on how to interpret the entire contents of the record.

Does Pervasive.SQL take advantage of multiple processors?

Pervasive.SQL fully supports symmetric multiprocessing (SMP) and multiple processors because it is multi-threaded and thread safe. However, Pervasive.SQL does not take direct advantage of any call specific for SMP and is not multiprocessor aware.

In an SMP environment, the operating system schedules available threads on the available processors, including threads for Pervasive.SQL. Since Pervasive.SQL is multi-threaded and thread safe, SMP can yield a performance boost for up to four CPUs. No significant advantage has been shown, however, to bypass the operating system scheduling and use SMP-specific calls to become SMP aware. This is because, in most cases, slowness occurs from disk I/O and not from CPU use.

How do I run Pervasive.SQL in trace mode?

Server

You must have administrator privileges on the machine where the engine is located that you want to run in debug mode. Using PCC, double-click Configuration for the desired Server engine. Choose Server4Debugging4Trace Operation and set the value to On. Click Edit4Apply. You do not need to restart the engine.

See also Trace Operation in Advanced Operations Guide.

Note
After tracing operations, you should turn off Trace Operation, making sure to click Edit4Apply when finished. You will notice slower performance if you run Pervasive.SQL in trace mode.

Win32 Client and Btrieve Win16 Client

Run the PSA network connectivity tests to verify network connectivity. See Test Active Installation Tasks . Also refer to the Pervasive Knowledge Base (http://support.pervasive.com/eSupport) for information about particular issues.

In addition, client tracing is available for troubleshooting certain types of low-level problems. Generally, low-level tracing is not required, so this type of tracing is intended for use by trained support staff. Your product vendor or Pervasive Software Support will explain how to conduct low-level client tracing.

Does garbage collection occur in the data files and indexes? For example, is space from deleted records recovered or reused?

Yes, space from deleted records is re-used on subsequent inserts. Space in files is never de-allocated back to disk. If index balancing is turned on, then unused space in index pages is also re-used. See Rebuild Utility Concepts in Advanced Operations Guide for information about using the Rebuild utility.

Is database shadowing available, allowing a complete up-to-date second copy of the database to exist on another drive or machine?

Pervasive.SQL does not contain specific functionality for this, but many customers have successfully used hardware mirrored drive arrays and solutions like Vinca's (now acquired by Legato) Standby Server to provide this functionality. Pervasive.SQL 2000i SP3 and later supports Pervasive's data replication product, Pervasive.DataExchange. Pervasive.DataExchange can be used to synchronize all or part of two or more databases.

What is the mechanism that allows the database to be backed up online? What happens if the server goes down in the middle of a backup with many open transactions?

Continuous Operations allows you to put a set of data files in a special "safe mode" so that they can be safely backed up while in use. While data files are in Continuous Operations mode, they are not modified, and special delta files store the results of any database operations. After the backup is complete, the data files must be removed from Continuous Operations mode, at which time the changes stored in the delta files are rolled into the live files.

If the server goes down while files are in continuous operations mode, the next time the data file is accessed, the database engine detects the existing delta file and rolls in the changes at that time.

You can put data files into Continuous Operations mode by using the BUTIL -STARTBU command or Maintenance utility described in Advanced Operations Guide.

Prev
Error Messages from PCC 		Contents
Up
Check for Revisions 		Next
Pervasive.SQL Resources and Contacts