That is interesting:
[HKEY_CURRENT_USER\Software\Pervasive Software\Communications Requester\Version 7\Settings]
"SatEntry0"="Proton,2,3,0"
"NumSatEntries"=dword:00000001
"SatEntry1"="Proton,0,4,3"
That's showing two different connection methods to the same server (Proton). The first is showing a LANMAN (WIndows) server using Namepipe address resolution and the second is showing and unknown server using DNS name resolution with a Lan adapter number of 3. This tells me that there might be more than just the registry problem. Is there anything in the PVSW.LOG on either the client or server around when these problems occur?
This information was pulled from the following Pervasive KB:
Solution Details
Solution ID: 00014450
What is the purpose of the SAT entries
Problem Description:
Problem Environment:
Pervasive.SQL v7
Pervasive.SQL 2000
Pervasive.SQL V8
SAT Entry
Cause of this problem:
Solution Notes: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.
The location of the SAT entries is
HKEY_LOCAL_MACHINE\Software\Pervasive Software\Communications Requester\Version 7\Settings
and beginning with Pervasive.SQL 2000 service pack 2
HKEY_CURRENT_USER\Software\Pervasive Software\Communications Requester\Version 7\Settings
For Pervasive.SQL V8 the location of the SAT entries is:
HKEY_LOCAL_MACHINE\Software\Pervasive Software\Communications Requester\Version 8\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 mechanism. 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.
Mirtheil
Certified Pervasive Developer
Certified Pervasive Technician
