Failed to connect to Pervasive.SQL 2000i database via TCPIP using the Pervasive.SQL Control Center (PCC)
(Last modified: 10Oct2002)
This document (10072805) is provided subject to the disclaimer at the end of this document.
fact
Novell NetWare 6.0
Support Pack 2
Pervasive.SQL 2000i database
symptom
Failed to connect to Pervasive.SQL 2000i database via TCPIP using the Pervasive.SQL Control Center (PCC)
Communication test fails over TCPIP using PCC.
Transactional tests fail over TCPIP during the testing phase of the PCC installation.
Relational tests fail over TCPIP during testing phase of the PCC installation.
Transactional and relational tests fail over TCPIP using the Pervasive System Analyzer.
Communication stress tests fail using Pervasive's Smart Scout System Qualification utility.
cause
Cannot resolve the server name or the registry entry for the Pervasive software communication SatEntry's hold wrong information. The Pervasive.SQL Control Center (PCC) works best over TCP/IP. In fact all "relational" operations performed with PCC require TCP/IP connections. It may be possible to create a new engine without a TCP/IP connection and even get into the configuration of that engine, however, attempting to access the actual NAASADMIN database components without a proper TCP/IP connection will result in failure.
fix
1. Make sure that the server name can be resolved via DNS, WINS, or a HOSTS file entry on the workstation itself. The Pervasive Smart Scout System Qualification utility or the Pervasive System Analyzer can help in determining whether or not the pervasive client can indeed resolve the server name to an IP address. (See Note)
2. Start | Run | regedit
Go to: HKLU\Software\Pervasive Software\Communications requester\Version 7\Settings
Delete all "SatEntry<number>" keys. There may be several. For example: SatEntry0, SatEntry1, SatEntry2, etc...
Modify the "NumSatEntries" key and set the value to "0".
Close any Pervasive utilities that may have been running including PCC and then relaunch the Pervasive.SQL Control Center (PCC). This will force PCC to read the registy information again.
If TCP/IP is available on both the workstation and server, the server name can be successfully resolved to an IP address (suggest using a HOSTS file entry for this), and the registry keys for SatEntry have been reset by following the instructions above then the PCC will be able to make a TCP/IP connection. All transactional and relational operations will also be functional.
Further Pervasive connectivity troubleshooting guides
1) The main tool to check connectivity problems is the Pervasive System Analyzer. PSA has been enhanced since P.SQL 2000 SP3 and is available as a standalone download from http://www.pervasive.com/support/updates/psa_update.asp. If you're not familiar with PSA, there is a Webinar archive that discuss its use available at http://www.pervasive.com/training/webinar_arch.asp. If the Pervasive Contol Center has been installed on the workstation then PSA is already installed and available as an option under START | PROGRAMS | Pervasive | Pervasive.SQL 2000i | Utilities.
2) Configure your P.SQL client to use TCP/IP as the only the communication protocol. Make sure both the Btrieve and P.SQL ODBC engine on the server are both configured to use TCP/IP. These can be done by following steps.
2.1) Configuring Pervasive Client
Use PCC on the client (Your client machine name will be displayed under Pervasive Engines), go to Configuration, Client, Communications Protocols, and set Supported Protocols to Microsoft TCP/IP only
2.2)Configuring Server
Use PCC, Register the server, go to Configuration, server, Communications Protocols, and set Supported Protocols item and also ODBC Supported Protocols item to Novell TCP/IP.
After this, the client and the server need to be restarted (PCC and NetWare server)
3) P.SQL 2K SP3 can use either DNS or NDS to resolve a NetWare name into an IP address.
3.1) For NDS to work, you need the Novell client installed at the workstation. The target server must be in the same NDS tree that is you current context, and the server must be v5.0 or later. The detailed connection test log from PSA (PVSW.LOG) would say whether or not it was able to resolve the name via NDS. There is a PVSW.LOG file on both the server and the client. On the server it is located in SYS:System. On the client it is in the Windows directory (i.e., C:\WINNT for NT/W2K machines).
3.2) The easiest way to check DNS is to simply 'ping' the server by name; if ping
works then the P.SQL client should work as well.
4) If the server has multiple IP address (perhaps because of multiple NICs), then check which IP address the client is actually sending to. If there is a public IP and a private IP address, then you probably want to make sure the client is pinging the private address. If pinging by server name fails, try pinging the server's IP address directly. If that fails, then there is some sort of network problem preventing the client from attaching.
5) Check whether the client has to go through a firewall to get to the server. That of course is not common on a LAN, but in the case of a server with multiple IP address where the DNS query returns the public IP address instead of the private address it can happen. If you must go through a firewall, you need to open ports 1583 and 3351 (decimal) for P.SQL to work.
.
note
Using the Smart Scout System Qualification utility to troubleshoot connection issues between the Pervasive client and database running on the server.
1. Start | Run | sscout32
This will bring up the Pervasive Smart Scout System Qualification utility.
2. Click the System Tests tab and make sure the following parameters are entered:
Engine to test = Btrieve
Protocol = All available
Testing Level = Communications Stress Tests
Target = \\<servername> (i.e \\FS1_NW6)
3. Click "Run Tests" button at the bottom.
4. Normally if the workstation can communicate via TCPIP the "Test output" screen will scroll with information for a short time and then a box will pop up with the title "System Test". Notice when this box pops up it will have a message in it that says:
"System stress tests - will run until canceled by user.
TCP/IP: Requests prcoessed: <number>"
The number will be incrementing very quickly. If this box pops up then TCPIP communications are good. When you press "Cancel" a the last line in the "Test ouput" screen will read "Test completed on <date and time>".
If there is a problem with TCP/IP communications then the "System Test" message box will never appear. Instead the the "Test ouput" screen will simply say "Test completed <date and time>". If this is the case proceed to step 5.
5. The test ouput screen is split into 6 steps the most important for troubleshooting are steps 1-3.
Step 1: Establish the workstation environment - In this section check to be sure that the TCP/IP protocol is reported as "available". There will be a line that says "Winsock TCP/IP is available".
Step 2: Determine full target name - Scroll through this section until the line just before step 3 can be viewed. The line just above the line that reads "Step 3..." should show the fully qualified target name. This name is the entry that was placed in the "Target" field and should be the NetWare 6 server. For example my line reads: "Fully qualified name MPRAY_60\".
Step 3: Resolve full target name into a network address - this section is normally of most use. This section will show whether or not the pervasive client is able to resolve the server name via DNS. The PCC must resolve the server name either via DNS, WINS, or HOSTS file. If the PCC is unable to resolve the server/target name then it will show in this section. If the system test shows errors resolving then check DNS and WINS to be sure name resolution is possible. If all else fails then create an entry in the HOSTS file for the workstation to resolve the server name to an address.
Step 4: Establish a connection to the target engine - This section will simply show whether a TCP/IP connection was established or not.
Step 5: Send data to/receive data from target server - This is specific to a successful TCP/IP stress test.
Step 6: Terminate established connection - simply names the connection that is terminated and returns the test completed section.
INFO on SatEntry in the registry
With Pervasive.SQL 7.0 and Pervasive.SQL 2000, a entry was added to the local BTI.INI or registry called SAT entries. They are used as a persistent cache that maintains information about the server, server type, and connection type. HKEY_CURRENT_USER\Software\PervasiveSoftware\CommunicationsRequester\Version 7\Settings
Each SAT entry has the following form:
SatEntry=ServerName with values of NOS, AddressResType, LANA
ServerName is the name of the file server
NOS is the Network Operating System with the following values:
0 = Unknown Server
1 = NetWare Server
2 = LANMAN server (including Windows NT)
3 = Local Drive
AddressResType is the Address Resolution Type with the following values:
0 = Unknown Address Resolution
1 = Bindery Address Resolution
2 = NDS Address Resolution
3 = Namepipe Address Resolution
4 = DNS Address Resolution
5 = Windows CE
6 = NetBIOS
LANA is the Lan adapter number which is a Virtual ID assigned by Windows to tell it whether NetBIOS is bound to SPX or TCP. With TCP or SPX, this value will not be present. The SAT entries are not directly based on any other registry settings or external files, but are affected by which transport protocols and which networking client software is installed at the workstation. During Pervasive's Network Service Layer (NSL's) initialization, it attempts to figure out if TCP/IP, SPX, and/or NetBIOS is available to it and whether or not the Novell Client and/or the Microsoft networking clients are installed. The NSL may use any address resolution method that is appropriate based on available transports or network clients.
For the NOS portion of the SAT entry, the values are based on the following:
0 (Unknown) - NSL was unable to determine the target NOS; typically it is either a NetWare server, or the target server name was a dotted notation IP address in an ODBC DSN, or the target Pervasive.SQL engine is a Workgroup engine and not a server engine.
1 (NetWare) - typically set when NSL resolves the server name through either through the Bindery or through NDS (not DNS), and thus requires either that SPX be installed (that is NSL's 'trigger' to check the Bindery) or that the Novell client (calwin*.dll, clnwin*.dll) be installed; also see Note 1.
2 (LANMAN) - typically set when NSL is able to make a Named Pipe connection to the server, but see Note 1.
For the address resolution type of the SAT entry, the values are based on the following:
0 (Unknown) - should never happen, really just a placeholder.
1 (Bindery) - requires SPX, a NetWare client (either Novell's or Microsoft's) and that at least one NetWare server be present on the LAN. You should only see this value when the target server is a NetWare server or an NT server running Microsoft's File and Print Services for NetWare.
2 (NDS) - requires the Novell client (calwin*.dll, clnwin*.dll). You should only see this value when the target server is a NetWare 4.x or 5.x server.
3 (Named Pipe) - requires a Microsoft networking client and that the target server be an NT server engine. For Btrieve applications connecting to an NT server engine, this should always be the resolution method used. Note that you would not see this when the target is a Workgroup engine, even if the engine itself is running on a NT machine.
4 (DNS) - requires TCP/IP; typically you should only see this for NetWare servers, but you also can see it for P.SQL 2000 DSN's that specify an IP address as the server name.
5 (Windows CE)
6 (NetBIOS)
Note 1: Prior to P.SQL 2000 SP2, the Win32 NSL would get a list of all connected drive letters and determine which type of NOS (NetWare or Microsoft Windows) the drive was mapped to. (The NSL programmatically did a 'net use' command, and examined the value in the 'Network' field.) The very first time the NSL wrote out a SAT entry for one of the connected servers, it used this information in deciding which NOS value to put in the SAT entry. Due to an apparent defect in Novell's latest client however, this action had to be removed. Also realize that this is true only for the first time the particular SAT entry is created. For subsequent connections, NSL will use the NOS value in the SAT entry no matter what the 'net use' command tells it.
Note 2: Once NSL has created a SAT entry for a specific server name, it will continue to use the address resolution mechanism listed in the SAT entry as long as it can still get a valid server address with that mechanism, even if another mechanism might be more appropriate. For example, suppose you have a NetWare server named Server1, and NSL created a SAT entry for Server1 indicating that it used DNS (not NDS) to get the TCP/IP address. Next, and you down the NetWare server and brought up an NT server also named Server1. If NSL is still able to get the NT server's address via DNS, it will continue to do so instead of using the Named Pipe echanism. If you wish to change the SAT entry, it is best to simply set the NumSatEntries value to 0 (zero), and let NSL recreate all of its entries.
Note 3: NSL only reads the SatEntryx values during initialization, and always writes them immediately prior to unloading. Thus, changing any SatEntry values will have no affect on any running NSL's, and will be overwritten when any running NSL is unloaded. If you wish to change any of NSL's registry values via regedit.exe, make sure that the NSL is not currently loaded by any running application.
.document
| Document Title: | Failed to connect to Pervasive.SQL 2000i database via TCPIP using the Pervasive.SQL Control Center (PCC) |
| Document ID: | 10072805 |
| Solution ID: | NOVL81044 |
| Creation Date: | 23Jul2002 |
| Modified Date: | 10Oct2002 |
| Novell Product Class: | Netware |
disclaimer
The Origin of this information may be internal or external to Novell. Novell makes all reasonable efforts to verify this information. However, the information provided in this document is for your information only. Novell makes no explicit or implied claims to the validity of this information.
Any trademarks referenced in this document are the property of their respective owners. Consult your product manuals for complete trademark information.