I'm running Pervasive 2000i Server on W2k Server. Only protocol used
is tcp/ip. A single client application makes only transactional calls.

There is an occasional event during which this client application
needs to open about 96 data files. About 1 in 4 times that this
happens the Requester returns a status 3105 on one of the Open calls.
All subsequent transactional (Btrieve) calls fail, usually with 3014.

I understand that status 3105 means the client can't find a network
transport protocol (tcp/ip in my case) to use to connect to the
server. Indeed, I find that tcp/ip is basically ‘fried' on the
workstation after this happens. You have to restart the machine to fix
the problem.

Error only occurs when the client attempts to open all 96 data files
in immediate succession. I can open the same data files in smaller
groups without failure.

Problem happens on every client workstation I test on.

It seems the Pervasive client is actually causing the problem. Anyone
have any idea what's going on?

That does not make any sense actually.
Whether it opens 1 file or 1000 there is only 1 network socket
conection.* *An application can use multiple sessions each with
their own connection but this is not normally done.

The 3105 is actually "no common supported protocol".
In the process of making the client server connection there is a
pre-connection made and the client and server handshake some
information. Part of the information is the address of the server and
protocols available at the server. It could be this initial call is
failing or the server is returning incorrect information.
Check the pvsw.log at the server to see what protocols (if any) are
failing at the server.

Try running the SmartScout utility network connection test on the
client to see what information is being sent back. "Before" and
"after" could provide useful information.

If a reboot of the client does resolve the issue it is not likely to
be caused by the server.

You do not make mention of what OS the client is?
Also what network client is used? MS client for MS networks?
Any 3rd party firewall software (or hardware)?
Any viruses, trojan horses or backdoors floating around on the
network?

Leonard

On 9 Feb 2004 18:08:28 -0800, Dan (AT) redridge (DOT) com (Dan W) wrote:

Dan W wrote:

Here's a few things from the knowledgebase that might help.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Pervasive.SQL Service & Support Classes ***
Chicago: March, 2004: See our web site for details!


FYI: Troubleshooting a Status 3105
Environment: Pervasive.SQL 2000
Published: August 2001
Description: Status 3105 when connecting to server and pvsw.log shows
status 8505.
Status 3105 when running a windows application.
Status 3105 after installing Pervasive.SQL2000.
Status 3105 when trying to launch application.
Status 3105 when trying to use the Function Executor utility.
Status 3105: No available transport protocol for the Pervasive Network
Services Layer.
Solution: Some of the strategies implemented to solve a status 3105 are:

1. Set the value for `TCP/IP Multihomed' to `On' in the Pervasive Control
Center. (This is located under configuration for the server, in the
communication protocols folder.) The default for this setting is `Off',
and you will need to turn it `On' if you have multiple network cards in
the server.

2. No transport protocol that is common to both the target server engine
and clients is available. For example, this status code could be caused
by a client using SPX when the server engine only has TCP/IP available.

3. Run the `SmartScout' utility to determine which protocol(s) are working
correctly. Check the Supported Protocols setting within the Communication
Protocols folder for both the client & server. Make sure that the correct
protocol(s) are selected. (i.e., whichever protocol(s) passed using the
SmartScout utility. )

4. If you are using the TCP/IP protocol, be sure that you can ping the
server by both name and IP address. Be sure that when you ping the server
by name, the correct IP address for the server is returned. If not, you
may need create a host file, or edit the host file you have with the
server's correct IP address.

5. You may need to limit the supported protocols in the Pervasive Control
Center for both the client and server to the one protocol which is being
used (i.e., the one that passes using the SmartScout utility).

6. If you are using firewall software or going through a router, be sure
that the appropriate ports are open on the firewall or router (3351/tcp
for Btrieve, 1583/tcp for Pervasive.SQL 2000 ODBC & 3352/tcp for
Pervasive.SQL7 SSQL; also ports 137-139 for NetBios authentication and
pipes (Btrieve NT only) ...or the alternative... port 2441/tcp for IDS
(Btrieve NT only).

7. If you're using a router (or firewall), be sure to look at
router/firewall issues which may be coming into play:
a) be sure that the router is configured to pass the type of packets
you're using--(i.e., SPX packets if using SPX or TCP packets if using
TCP),
b) If going through a router or firewall, be sure that you can
telnet to ports 3351 (for Btrieve), port 1583 (for odbc), and 3352 (for
SSQL), to ensure that the ports are open on the router or firewall.

8. If you have installed the Microsoft Proxy client, try removing it, or
reconfigure it to NOT route local requests through the proxy server.

NOTE: These suggestions were gathered from the customer interactions, and
may not apply to your particular situation.


FTF: When Installing the Client, an Error Message Is Received During the
PSA Tests: Server Appears to Have SPX Protocol, But the Address Returned
Does Not Seem to be a Valid Address
Environment: Pervasive.SQL 2000i SP4, Microsoft Windows 2000 Server
Defect: 40533
Description: When installing the client, during the PSA tests, the
following error message is received: 'The server you chose appears to have
the SPX protocol but the address returned does not seem to be a valid
address'. When using Function Executor from the client to access a file
on the server, a status 3105 is received, yet accessing the same file
using Function Executor locally at the server works fine. The server's
pvsw.log shows the message: 'Error initializing the TCP/IP protocol, error
code 6'. In the Pervasive Control Center for the server, the configuration
setting under the 'Access' folder for 'Accept Remote Requests' says 'Off.'
If you attempt to turn it 'On', after restarting the two Pervasive
services, it still says 'Off'.
Solution: There is an FTF for this issue.


FTF: Application would not connect when running across a WAN and returned
status 3105.
Environment: Pervasive.SQL 2000i NT/2000, Service Pack 4
ID: psql5423
Defect: 35055 FTF
Description: Application would not connect when running across a WAN and
returned status 3105.
Example: Status 3105 -"No available Transport protocol for the Pervasive
Network Service Layer"
Cause: The named pipe call to the server was not completing in time due
to network latency.
Solution: An FTF is available that addresses this issue.


DE - Problems with FailOver on Windows 2000 Servers
Engine: Pervasive.SQL 2000i
Version: All
Platform: Windows 2000

Issue:
After our phone conversation it appeared that everything was working fine.
However this morning when we failed over from the primary card (2000
server) to the backup card we experienced the same errors from pervasive.

Using PFE I was able to trap three specific codes.
When I first try to open the data file I receive: 3106: The Pervasive
Network Services Layer encountered a connection failure
If I close the "Btrieve Error" window and try to reopen the data file I
receive: 3014: The MicroKernel router cannot find an engine
I closed and reopened the PFE program and this time I received: 3105: No
available transport protocol for the Pervasive Network Services Layer

Additional information; After waiting an hour I was able to open the files
without any problem. It appears there is a latency in the name resolution
when we switch the IP address between cards. One thing I tried was mapping
the drive letter using the server name (FSNT) and remapping using the IP
address (192.168.1.20). Until the hour was up neither would work, after an
hour both worked.

Based on Leonard and Bill's replies I did some more investigating:

The server has three network cards (one on-board and two gigabit ports
on an adapter), but only one is Enabled and it's the only one with an
IP address. "TCP/IP Multihomed" was initially set to On. I changed
‘TCP/IP Multihomed' to Off and set the "Listen On" ip address to the
servers only ip address. So far I haven't been able to duplicate the
problem since this adjustment.

I use Microsoft TCP/IP everywhere. No other protocols are installed
anywhere, and the server and client Pervasive communication parameters
are all set to use TCP/IP exclusively.

The client OS is Windows 2002 Server SP3. The clients are actually
stand-alone web servers and they are networked through a single switch
using Windows networking to the Pervasive SQL server which is also
Windows 2000 Server SP3. The server and all of the clients are behind
a firewall, but no firewall between them.

Smart scout does not show any problems before the 3105. After I cause
the 3105 Smart Scout cannot find the server and the client cannot
resolve any machine names on the network ("ping machinename" fails,
which is why smart scout can't find the server), but it can ping the
other machines by ip address. IPCONFIG shows the correct DNS ip
address, I can ping the DNS server by ip address, the DNS server is
functioning properly, but the machine refuses to actually resolve any
names. IPCONFIG /DISPLAYDNS shows the server name as invalid,
/FLUSHDNS does not resolve the problem.

Again, until I made the TCP/IP Multihomed adjustment I could reproduce
the 3105 on any of four different clients about 25% of the time by
triggering the procedure that causes the client application to open 96
data files in succession (they're normally opened a few at a time).
The 3105 was returned on an Open call.

I'll re-post if the problem reoccurs.