Pervasive logo

Prev User's Guide Next

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 saying "'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 . You must first make sure that a server DSN exists on the server you want to access.

I get a message saying my 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 Pervasive System Analyzer (PSA). The same message is also logged in the client's PVSW.LOG file. This message is only a warning. The client is not prevented from connecting to the engine in this situation. Pervasive Software does test older clients against newer engines, but guarantees compatibility between engines and clients only if the clients are the same version as, or newer than, the 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 or greater than the engine version.

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:

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 a Windows client, double-click Network Neighborhood and see if you can find the server computer that you want to connect to. 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 login to the correct network. For example, if you have both NetWare and Windows NT servers in your environment, it is possible to be logged into the NetWare network but not the Windows NT network, or vice versa. If you're not logged into a particular network, you can't access the servers on that network at all.

Note
If you are trying to create a new database on the server, to use Monitor against the remote server engine, or to use Configuration against 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.

  1. The next possibility is that the client requester is disabled.

    Choose Start4Programs4Pervasive.SQL V84Control Center to start PCC. Using PCC, double-click the icon that represents your local client computer. Double-click Configuration and choose Client4Access4Use Remote MicroKernel Engine. Make sure this setting is set to On.

    You can now rule out the requester as the source of the problem.

  2. Next, verify that Pervasive.SQL is installed and running on the target server.

    On Windows NT, go to the server console and open the Services Control Panel and verify that "Pervasive.SQL (relational)" and "Pervasive.SQL (transactional)" have been started. If not, start these services.

    On Windows 2000, go to the server console and open the Administrative Tools Control Panel and then double-click on the Services icon. Verify that "Pervasive.SQL (relational)" and "Pervasive.SQL (transactional)" have been started. If not, start these services.

    On NetWare, enter the command BSTART or MGRSTART at the NetWare prompt. If Pervasive.SQL is not loaded, these commands load Btrieve and the SRDE, respectively. If Pervasive.SQL is already running, you receive the message "Modules already loaded."

    On Linux, type the following command at the Linux prompt on the server where the database engine is installed: 

    ps -e | egrep 'mkded|sqlmgr' 

    
   If the output from the command returns at least one line containing the text "mkde" and at least one line containing the text "sqlmgr," then Pervasive.SQL is running. If you do not see these lines, then you need to be logged into the root account and start the database engine by entering 
    /etc/rc.d/init.d/psql start

    

    
   You can now be certain that the server engine is installed and running.
  3. The next step is to ensure that the server engine is accepting remote communication requests.

    In PCC, use Configuration to make sure that the remote database engine is configured to accept remote requests. If you are having difficulty accessing a Windows NT server engine remotely, then you must use Configuration at the server itself. You must have administrative permission on the server (or membership in the Pervasive_Admin group) in order to do so. Connect to the server in PCC, double-click Configuration for the target server, then choose Server4Access4Accept Remote Request. Be sure the value is set to On.

    You can now rule out the possibility the server is not accepting remote requests.

  4. 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, connect to the server, open the Databases folder 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.

    Right-click on the Databases folder for the target server, and choose New Database. 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.

  5. 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 . 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.

  6. The final task to perform is to ensure that your client and server are communicating on the appropriate network protocols. By default, Pervasive.SQL 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 network or a 100% Microsoft network, then your preferred protocol is TCP/IP. If you have a NetWare network, then you need to find out from your NetWare administrator whether you should be using IPX/SPX, SPXII, or 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. Using PCC, connect to the target server. Double-click Configuration, and click Server4Communication Protocols4Supported Protocols. Click ... and ensure that the correct vendor and protocol stack is listed in the Selected column. Immediately above that setting, choose ODBC Connection Manager Supported Protocol. This setting should be set to TCP/IP unless you are configuring a NetWare server that does not have TCP/IP installed.

    Ensure that your client is using the same protocol. Using PCC, double-click the icon for your local machine. Double-click Configuration, and choose Client4Communication Protocols4Supported Protocols. Click ... and ensure that the correct vendor and protocol stack is in the Selected column.

  7. If you have performed all of the above tasks with no success at accessing your data, refer to Pervasive.SQL Resources and Contacts for more ways to get help.
Prev
Basic Troubleshooting		 Contents
Up
Check for Revisions 		Next
Error Messages from PCC