Basic Troubleshooting
How to Identify Problems and Find Solutions
The following topics provide information for troubleshooting and resolving common problems.
General Troubleshooting
This section provides some basic troubleshooting procedures to help you rule out possible causes for situations you may encounter. This section covers the following topics:
I get Error 1114 when trying to access my data
or
I get an error about ServerDSN or DBQ was not found in the connection string
PCC can access remote server data sources (DSNs) using connections without client DSNs. Many desktop applications, such as Microsoft Excel and Microsoft Access, cannot do this. You must create a client DSN on your local computer to provide access to data on the server through the remote server DSN. To create a client DSN, follow the instructions in
Setting Up Client Access from a Windows Client. You must first make sure that a server DSN exists on the server you want to access.
I get a message about Engine components’ version is different than my client components’ version
When a client requester first connects to an engine, the client requester compares its internal router version with the value returned from the engine by a Btrieve Version (26) call. If the client version is older than the engine, a message dialog box is displayed on the client system with the message “Engine components’ Version is different from Client’s” along with a suggestion to run PSQL System Analyzer (PSA). The same message is also logged in the client’s PVSW.LOG file.
This message is a warning. The client is not prevented from connecting to the engine in this situation. However, Actian Corporation guarantees compatibility between engines and clients only if the clients are the same version as the database engines. When prompted by this message, if you choose not to run PSA and archive your old client components and install a newer client, you can expect the product to behave unpredictably until the client version is equal to the engine version.
Note Actian Corporation recommends that you use client requesters that are the same version as the database engine. If you choose, you may use a client requester that is an older version than the database engine with which it interacts. In some situations, depending on the type of SDK access method used by your application, an older version requester will not work with the database engine. Your application will be unable to communicate with the database engine. For those situations, you must use client requesters that are the same version as the database engine.
Client requesters that are a newer version than the database engine may or may not function correctly. Actian Corporation does not guarantee that newer versions of client requesters will function correctly with older versions of the engine. Therefore, Actian Corporation recommends that you avoid the use of newer version client requesters with an older engine.
I can’t get to my data on the server engine
If you cannot get to data on the server engine, your most likely causes are:
•The server computer is down or the network has been interrupted
•You do not have operating system rights to access the server, or you are not logged into the correct network
•The client requester is not enabled
•The database server engine is not installed or not running
•The database server is not accepting remote connections
•The remote database does not have a DSN set up to advertise on the network
•The local client does not have a DSN to access the server
•The client or server network configuration is wrong
►To determine the actual cause of the failure
Follow the steps below to rule out certain root causes and narrow down the possible sources of failure.
1 From the operating system on a Windows client, access the Network information and see if you can find the server computer to which you want to connect. If you can see the server, you can rule out that the server is down or disconnected from the network.
2 Next, try to map a drive to the file server or open a shared file on the server. If you can successfully connect to the file server and create a file on the mapped drive, then you can rule out lack of operating system rights. You can also rule out failure to log in to the correct network. If you are not logged in to a particular network, you cannot access the servers on that network.
Note If you are trying to create a new database on the server, to use Monitor against the remote server engine, or to configure the remote server engine, you must have administrative rights on the server, or be a member of Pervasive_Admin. A simple drive-mapping or shared-file read will not tell you whether you have administrative rights. This means you may be able to connect to the file server, but you still may not be able to connect to the database engine with Configuration, Monitor, or Create Database Wizard.
3 The next possibility is that the client requester is disabled.
Start PCC and right-click the icon that represents your local client computer, then select Properties. Click Access and ensure that Use Remote MicroKernel Engine is selected.
You can now rule out the requester as the source of the problem.
4 Next, verify that PSQL is installed and running on the target server.
On Windows, open Services under Administrative Tools. Verify that PSQL Transactional Engine and PSQL Relational Engine have been started. If not, start these services.
On Linux or macOS, type the following command at a prompt on the server where the database engine is installed:
ps -e | egrep 'mkded'
If the output from the command returns at least one line containing the text mkde, then PSQL is running. If you do not see this line, then you need to be logged into the root account and start the database engine by entering /etc/init.d/psql start on Linux and /usr/local/psql/etc/init.d/psql start on macOS.
You can now be certain that the server engine is installed and running.
5 The next step is to ensure that the server engine is accepting remote communication requests.
In PCC, ensure that the remote database engine is configured to accept remote requests. If you are having difficulty accessing a Windows 32-bit server engine remotely, then you must check the setting at the server itself. You must have administrative permission on the server (or membership in the Pervasive_Admin group) in order to do so. In PCC, right-click the server and select Properties. Click Access and ensure that Accept Remote Request is selected.
You can now rule out the possibility the server is not accepting remote requests.
6 Note: If your application uses pure Btrieve access only, without ODBC, then skip this step.
If everything checks out so far, but you still cannot get to the data you want to access, make sure a server DSN has been set up for your target data. Using PCC, expand the Databases node for that server and inspect the databases that are present. Make sure one of the databases represents the data you want to access. If so, then a server DSN has been created for your data.
If you do not find the data you want to access, but you know it is on the server, then most likely you need to set up a DSN for the given data. You must have administrative rights on the server (or be a member of the Pervasive_Admin group) to do so.
Follow the instructions in
Setting Up ODBC Database Access to set up a DSN for existing data files.
You can now rule out the server DSN as the source of the problem.
7 Note: If your application uses pure Btrieve access only, without ODBC, then skip this step.
If you have performed all the steps above and you still cannot get to your data, the next possibility is lack of a local client DSN for the remote data.
PCC can access remote server DSNs using connections without client DSNs. Many desktop applications, such as Microsoft Excel and Microsoft Access, cannot do this. You must create a client DSN on your local computer to provide access to the remote server DSN. To create a client DSN, follow the instructions in
Setting Up Client Access from a Windows Client. You must first make sure that a server DSN exists on the server you want to access.
You can now rule out the client DSN as the source of the problem.
8 The final task to perform is to ensure that your client and server are communicating on the appropriate network protocols. By default, PSQL ships with all network protocols enabled, so connection time may be slow as it tries all protocols, but it should eventually connect. Some application vendors disable the protocols that are not typically used by their application(s).
First, determine what protocols ought to be used on your network. If you have a Linux or macOS network or a 100% Microsoft network, then your preferred protocol is TCP/IP.
Once you know what the protocol should be, you should ensure that your server is using this protocol. You must have administrative rights on the server operating system (or be a member of Pervasive_Admin) to perform this task. In PCC, right-click on the server name and select Properties. Click Communication Protocols. Ensure that the correct protocol is listed in the Supported Protocols list and that TCP/IP is selected.
Be sure that your client is using the same protocol. Using PCC, right-click Local Client and select Properties. Click Communication Protocols and ensure that the correct protocol is selected in the Supported Protocols list.
9 If you have performed all of the above tasks with no success at accessing your data, contact PSQL Support.
PCC runs slowly or hangs when retrieving large record sets
If this problem occurs, try increasing the amount of memory available to PCC during start up. The amount of memory you can specify is limited by the physical memory installed on your machine. You can specify a minimum and a maximum amount of memory. For example, to specify a minimum and maximum of 256 megabytes, start PCC with the following command:
pcc.exe -vmargs -Xms256M -Xmx256M
The parameter -vmargs is required if you specify the other parameters.
The parameter -Xms specifies the minimum amount of memory to allocate to PCC. The parameter -Xmx specifies the maximum amount of memory to allocate to PCC. If you specify the -Xms parameter, you must also specify the -Xmx parameter.
Error Messages from PCC
You may receive several different messages when attempting to create or connect to databases in PCC. This section explains the likely causes for some of the most common error messages:
Can’t retrieve database names. You don’t have access rights for the operation
This error may occur when you are attempting to create a new database on the server. The most likely cause is that you are logged in as an operating system user that has neither administrative rights in the server operating system, nor membership in the Pervasive_Admin group on the server. Another likely cause is that you forgot to enter a user name and password.
Solution: Be sure to enter a user name and password for the remote operating system. You must have administrative rights on the server or be a member of the Pervasive_Admin group in order to create a new database on the server.
Granting Administrative Rights for the Database Engine explains how to set up the Pervasive_Admin group.
For Windows 32-bit platforms, be sure that you are set up as a local user on the system, not a network user. Network users have a domain name and a back slash preceding the user name, such as BOSTON\GILBERT. Be sure that the user who is a member of the Administrators group or Pervasive_Admin group is a local user.
If you have checked permissions and your user login does in fact meet one of the criteria above, then you should also check to make sure that you are logged into the correct network. You can verify whether you are logged into the correct network by attempting to read or write to a server that you are certain uses the target operating system.
Unable to connect to the specified remote server. Verify that all of the communication components are loaded on the remote server and that there are available sessions and try again
You may receive this error when attempting to register a new remote server in PCC. There are several reasons you may receive this error:
1 You mis-typed the server name. The database client tried to connect to a server that does not exist.
Solution: Double-check the name of the server, and make sure you can see it in your Network Neighborhood, spelled exactly how you entered it.
If you know the server exists but you can’t see it in your Network Neighborhood, make sure that you are logged into the correct network. Ask your network administrator for help.
2 The server user count has expired. If you have been using a temporary license, you will get this message for connection attempts after the license has expired.
Solution: Run License Administrator to check the status of licenses installed on the server. In the window that appears, you can see detailed status information on each license that has been applied to your server. If your license has expired, purchase a permanent license from your reseller or from Actian Corporation.
3 There are no available sessions on the server. If you have a heavy load of users on the server, or if you have configured the server with a small number of sessions, you may receive this error.
Solution: Run Monitor to check the usage of sessions available on the server. Check MicroKernel Communication Statistics. For Total Remote Sessions, if the Peak value and the Maximum value are the same, then it is likely that you have run out of sessions.
4 The remote database server is not running.
Solution: Make sure that the remote database engine is running, or ask your network administrator to do so.
5 The remote database server is not accepting client requests.
Solution: Set the properties to ensure that the remote database engine is configured to accept remote requests. You must have administrative permission on the server (or membership in the Pervasive_Admin group) in order to do so. In PCC, right-click the server name in PSQL Explorer and select Properties. Click Access and ensure that the Accept Remote Request option is selected.
An error was encountered while connecting to the server
The most likely cause of this error is using the wrong operating system user name or password in an attempt to connect to the server.
Other possible causes include:
•The operating system may be expecting the user to change his/her password on the first logon. This situation occurs if, in the User Manager, you have selected the User Must Change Password at Next Logon checkbox.
•If the user is a member of another group with lesser permissions, the lesser permissions will override the greater permissions. A user always has the most restrictive permissions of any group to which the user belongs.
Solution: Double-check the spelling of the user name and the password. Make sure the user and password have been set up on the remote server operating system.
Inspect the user’s account information on the server. Make sure the operating system is not expecting the user’s password to be changed at the next logon. Make sure the user is not also a member of a group that has restricted permissions.
For Windows 32-bit platforms, be sure that the user is set up as a local user on the system, not a network user. Network users have a domain name and a back slash preceding the user name, such as BOSTON\GILBERT. Be sure that the user who is a member of the Administrators group or Pervasive_Admin group is a local user.
Unknown configuration properties
It is possible, but unlikely, that PCC may retrieve configuration properties from the database engine that are invalid. Please contact PSQL Customer Support to report such error conditions.
Frequently Asked Questions
This section answers some of the questions that customers frequently ask.
Installation
PCC
Security
User Count, Session Count, Data In Use
Networking
Difficulty Accessing Data
ODBC and DDFs
Upgrading from Btrieve 6.15
Upgrading and Migration
Demodata Sample Database
How do I restore Demodata to its installation defaults?
3 In the list in the Select Database dialog, select DEMODATA, then click OK.
SQL Editor appears as a new tab in PCC.
4 Click File > Open.
5 Navigate to the location of the demodata.sql file and click Open.
For default locations of PSQL files, see
Where are the PSQL files installed? in
Getting Started with PSQL.
6 Click
SQL >
Execute All SQL Statements, press
F10, or click
.
The demodata.sql script deletes the existing tables then recreates them using the installation defaults. The restored tables are empty (no data).
Any new tables that you have created as part of Demodata are not affected.
7 Use the Bulk Data Utility (BDU) to populate the tables with data (see
bdu).
a. Open a command prompt.
b. Go to the "restore" directory for Demodata. An SDF file exists for each table in Demodata.
c. For each SDF file, use BDU to load the data into the table.
For example, to load the data for the Billing table use the following command. The comma is the field delimiter in the file.
bdu demodata billing billing.sdf -t ,
Note The -t parameter is required.
BDU returns the number of rows of data that were loaded.
Miscellaneous
Installation
Frequently asked questions about installation.
Will I lose my data files if I uninstall my existing version of the product, or install a new version?
When you uninstall PSQL or install a new version of PSQL, your data files and DDFs are never affected. Even when PSQL System Analyzer archives PSQL files, or even if you have your data files in the same directory as PSQL files, your data files are not affected.
Why do I not see in PCC PSQL Explorer the “plug-in” product that I just installed or upgraded?
What type of client install should I do?
If you are not sure, always select complete. This option performs a standard 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 PSQL v12 or later, start Monitor or Maintenance, choose Help then About from the menu, and check the Build Level.
Is PSQL 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 PSQL in a Failover environment? or
Can I install PSQL in a Clustering environment?
Yes. PSQL is cluster compatible with Microsoft Failover Clustering, Microsoft Cluster Service, and Linux Heartbeat. See
High Availability Support in
Advanced Operations Guide.
Can I install PSQL in a Load Balancing environment?
That is not supported at this time.
Can I install PSQL on a server running Btrieve v6.x or earlier?
No, you cannot run PSQL and Btrieve 6.x on the same computer at the same time.
How do I keep my Workgroup Engine from starting up automatically when I reboot?
You must remove it from the Windows Startup group. Check the operating system documentation for Startup.
PCC
frequently asked questions about PCC.
How do I start PCC on Linux or macOS?
Certain requirements must be met before you can start PCC. See
Starting PCC on Linux or
Starting PCC on macOS.
Security
Frequently asked questions about security.
When do I log in using an operating system user and password, and when do I log in 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 PSQL 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 PSQL 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, the Monitoring utility requires 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.
User Counts
frequently asked questions about user counts.
How do I authorize a User Count Upgrade?
See the tasks discussed under
License Administration.
How does a PSQL engine using the concurrent user license model keep track of how many people are accessing the data? If people access the data with two engines at the same time, what happens?
With the concurrent user license model, each license specifies a user count. A user count allows the specified number of computers to connect to the PSQL database engine concurrently. PSQL identifies machines by serial number, so all connections with the same serial number are recognized as coming from the same machine. A machine with multiple NICs, for example, is recognized as the same machine.
Each workstation that accesses PSQL as a client session counts as one user. Multiple applications on a single client computer are counted as one user, not separate users. Each Terminal Server session also counts as one user.
PSQL uses one user count for each unique incoming protocol from the same client computer session. If one application uses TCP/IP and another application uses SPX, two licenses are counted if both applications run on the same machine. If different address formats of the same protocol are used, only one user is counted. For example, if one application uses IPv4 and another uses IPv6, only one user is counted if both applications run on the same machine. IPv4 and IPv6 are just different address formats of the TCP/IP.
Only one engine is ever permitted to access data files at a time. The second engine to try to open the files is refused, because the engines open the data files in exclusive mode to avoid data corruption.
Does the Workgroup engine use concurrent or per-seat licensing?
I am thinking of moving from a PSQL engine with concurrent user licensing to one with capacity-based licensing. How do I determine the appropriate size for my data use license?
Capacity Usage Viewer was designed for this purpose. Because it records both peak daily session use and peak daily data usage, you can see how much of each you use over time. You can use this information to make a reasonable determination of what license capacity size you need. See
Capacity Usage Viewer for information about how to access and use Capacity Usage Viewer.
Networking
Frequently asked questions about 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.
Start PSQL System Analyzer and click Next on the Welcome screen. On 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 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
Frequently asked questions about accessing data.
I upgraded from Btrieve v6.x or earlier to the current version of PSQL. Now I get error messages telling me that a file is inaccessible when everybody else can get to it. What’s wrong?
Use PSQL System Analyzer to be sure that all components from previous versions of Btrieve or PSQL 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. (Note that hexadecimal values in message strings written to pvsw.log are preceded by “0x” to distinguish them from decimal values.)
Start PCC. Right-click Local Client and select Properties. Click Access. Ensure that the option Use Local MicroKernel Engine is not checked and that Use Remote MicroKernel Engine is checked.
I have files sitting on the server that are shared and yet PSQL cannot read them. What’s wrong?
How are the files shared? PSQL does not support mapping a drive letter using Redirected mapping under Microsoft, or using the hidden Admin share (C$) under Windows 32-bit platforms.
Make sure that users have appropriate operating system login credentials to access the file server.
Run PSQL 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 9 back to file format version 8, 7, or 6. 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.
In PCC, right-click the server name where the data files are located and select Properties. Click Compatibility and set Create File Version to the file version to which you want to convert. Click OK. Click Yes to restart the engines. These changes result in new files created to be in the version selected.
Run the Maintenance utility, then click Options then File 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 Data then Copy. 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
Frequently asked questions about ODBC and dictionary files.
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 file path in a DDF be changed?
In PCC, right-click the database for the table and select Properties. Click Directories. Change the value for Dictionary Location.
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, expand System Objects.
You can also use the ALTER TABLE USING statement in SQL to change the data file used by a particular table. See SQL Engine Reference for further information.
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 run-time 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 nonstandard 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 Relational Engine 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 nonstandard dictionaries, the DDFs file.ddf, field.ddf, and index.ddf do not exist. Such dictionaries do not work with PSQL products. For example, if you see a file called x$file.ddf, instead of file.ddf, you can assume your DDFs are nonstandard.
Nonstandard DDFs are unlikely to work properly with PCC 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 Sniffer?
DDF Sniffer was added to PSQL with the acquisition of Smithware in 1998. It is no longer available as a separate product. Its functionality has been incorporated into PCC and DDF Builder.
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 creating a DSN, why can I not open the files using ODBC?
If Btrieve files have owner names, you must use database security for ODBC access. Turn on database security in PCC. See
To turn on security using PSQL Explorer and
Owner Names and SQL Access in
Advanced Operations Guide.
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, see use PCC to find out. Right-click the table in PCC and select Properties. Click Information in the tree. The File Name 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 the CREATE GROUP and GRANT statements in SQL. You can also add users and groups with PCC. See
Users and Groups in
Advanced Operations Guide.
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 Relational Engine?
There is no DOS requester support for SQL applications, but the PSQL Client software for Windows includes ODBC client components allowing you to connect to a remote server engine.
Is ODBC the only method of access for PSQL?
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. PSQL stores data in separate files, one file per relational table definition. The metadata, such as data definitions and user and group definitions, are stored in DDF files, each file ending in the extension .ddf.
Does the Relational Engine have scheduler capabilities to run stored procedures or other types of scripts designed to access and affect data?
The Relational Engine does not have a scheduler.
Upgrading and Migration
Frequently asked questions about upgrading and migration.
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 file structure. The table creation wizard can derive some field definitions from file indexes, but after doing so, data segments may remain that contain more than one actual field. The wizard has no way of interpreting the contents. You must use your own knowledge of the record structure to split out these fields and build a table definition that matches all the fields in the record.
Miscellaneous
Frequently asked questions about miscellaneous topics.
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 or dump 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 PSQL can dump a record in ASCII-readable format is by reading the DDFs to get the complete specification for the record. Btrieve only has the record length, the data type of indexes and length of the indexes. Btrieve does not have information for interpreting other record content.
How do I run PSQL in trace mode?
Server
To run the engine in debug mode, you must have administrator privileges on the machine where it runs.
1 Using PCC, right-click the desired Server engine and select Properties.
2 Click Debugging, set the value for Trace Operation to On, and click OK.
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 Edit > Apply when finished. You will notice slower performance if you run PSQL in trace mode.
Windows Client
Run the PSA network connectivity tests to verify network connectivity. See
Test Active Installation Tasks. Also see the Knowledge Base at the PSQL website 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 PSQL 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 reused on subsequent inserts. Space in files is never deallocated back to disk. If index balancing is turned on, unused space in index pages is also reused. See
Rebuild Tool Concepts in
Advanced Operations Guide.
Is database shadowing available, allowing a complete up-to-date second copy of the database to exist on another drive or machine?
PSQL 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 the data replication product, DataExchange.
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.
. (See