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

•

I get an error about ServerDSN or DBQ was not found in the connection string

•

I get a message about Engine components’ version is different than my client components’ version

•

I can’t get to my data on the server engine

•

PCC runs slowly or hangs when retrieving large record sets

I get Error 1114 when trying to access my data

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.

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.

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.

The next possibility is that the client requester is disabled.

Start PCC then right-click the icon that represents your local client computer, then click 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.

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 OS X, 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 OS X.

You can now be certain that the server engine is installed and running.

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, then click 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.

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.

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.

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 OS X 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 then click 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 on Local Client then click Properties. Click Communication Protocols and ensure that the correct protocol is selected in the Supported Protocols list.

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.