We are using Pervasive v7 with a 3rd party software. We can't upgrade
Pervasive as the 3rd party software doesn't support it. We are using
TCP/IP protocol to connect to a remote database. Approx 100 clients
are using this software (not necessarily all at once).

The problem that we are having is that the client sessions appear to be
being dropped. Looking in to the PVSW.LOG file on a client machine
shows lots of status 3111, 3112, and 10054 messages.

I have looked these up and it appears that they are related to
connections to the database server being dropped. I have talked to our
IT dept and they claim that the network is just fine (of course). I
even had them install a sniffer on the client and on the server to
monitor transmissions. And for the 3 weeks that they monitored,
everything went smoothly (of course)!!! So I got no help from them.

It does seem that the problems coincide with periods of high network
usage, mostly when our IT dept is pushing out updates to computers.
They generally do these updates overnight and that's when the problems
usually occurr. We have batch processes that run overnight and it is a
real pain when they don't work.

Lately, these "disconnects" have been occurring pretty much nightly.
This coincides with the fact that IT is pushing out updates to McAffee
v8 and Win XP SP2. Factor in the 5000+ computers that they are
updating, and that makes for some heavy network traffic that could go
on for weeks.

I guess my main question is if there is a way to set Pervasive's
Timeout value so it waits longer before deciding the connection was
dropped? Or is there a way to set Pervasive to use retries?

Checking the Pervasive setup on my local machine, I noticed TCP/IP
Timeout value under Communications Requester. Could that be anything
useful? It is currently set to 15.


Server is Win2003 Server. Dual Intel Xeon processors. 6GB RAM.
Clients are XP, P4's 256-512MB RAM.

Thanks,
JBreits

Pervasive is a slave to the TCP stack -- if the TCP connection is lost,
ther's not much that they can do about it (kind of like most
cellphones). There are numerous settings that yuou can adjust on TCP
as Windows registry hacks, but this can have an adverse effect on other
processes, and is not recommended. See an advanced text on Windows
registry hacks for more details.

As you can guess, Pervasive addressed this with PSQL2000i SP3 by adding
the ability to automatically reconnect lost sessions, but you indicated
that upgrading to a newer version is not an option for you. I would go
back to your 3rd-party developer and find out why they are making you
live with technology from the last century. ;-)
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - July 19-22 ***
*** Chicago: Pervasive DataExchange Class - July 27-29 ***

JBreits wrote:

It should also be clarified that the addition of PARC (Pervasive
auto-ReConnect) into PSQL2000i SP3 does NOT eliminate the root cause of
the networking failures -- the network will STILL fail just as much as
it has ever done, unless the cause can be found and fixed. The use of
PARC DOES however provide a way for end users to live with the issue
(i.e. keep the application running without data loss) until it can be
resolved.

Users that enable PARC that still have networking problems will likely
start complaining of VERY slow performance and other temporary
"hanging" issues every time the reconnect code gets used. As such, it
should only be used as a stop-gap measure while a solution is found.

For sure, the best way to isolate the problem is to get a network trace
(from Sniffer, Ethereal, etc.) and have it analyzed by a networking
professional -- someone who can read, interpret, and troubleshoot trace
files. We do that for customers, but mainly in the Pervasive world
only.
Goldstar Software Inc.
Building on Btrieve(R) for the Future(SM)
Bill Bach
BillBach (AT) goldstarsoftware (DOT) com
http://www.goldstarsoftware.com
*** Chicago: Pervasive.SQL Service & Support - July 19-22 ***
*** Chicago: Pervasive DataExchange Class - July 27-29 ***

Bill Bach wrote: