Btrieve Error 3103

My first suggestion is to patch to Service Pack 3, of PSQLV8.7. This
may go a long way towards solving the problem.

We've seen "random" 3103's before caused by DNS and WINS problems on
networks. You may wish to make sure that when the problem occurs, you
can still PING the server by name, and you still get good name
resolution from both DNS and WINS.

As for your questions on comm threads:
1) Running out of threads will not "kill" the server. The thread count
indicates the number of simultaneous requests that can run. Any
requests beyond this number simply queue up and are handled when the
threads are free. In fact, it is possible to run on only 1 thread if
you wanted to (though it wouldn't be quite as efficient).
2) It depends on how many concurrent requests you have. If you are
seeing it reach the peak during normal operations, you may be able to
gain a bit in performance by increasing the thread count. This will
also increase the mewmory usage, so be careful there.
3) This can be caused by bad queries -- patching the engine is usually
the first step to troubleshooting it.
4) Not really. The best way to find it is with a network trace of all
traffic to and from the server, but this generates a LOT of data to
review, and it is not always straightforward where the problem lies.
If both services died simultaneously, then you might have something,
but with one shutting down first, this will be a tough one.
Goldstar Software Inc.
Pervasive-based Products, Training & Services
Bill Bach
BillBach@goldstarsoftware.com
http://www.goldstarsoftware.com
*** Chicago: Pervasive Service & Support Class - 03/2007 ***

Rob Michelis wrote:

> Hello,
>
> I have a pervasive 8.5 implementation that is throwing btrieve 3103
> errors intermittently. It is running on a windows box and has a user
> base of about 300 users. The database was originally a btrieve 6.0
> that has been upgraded through the years.
>
> When the clients start throwing the 3103 errors, you can't log into
> the monitor on the server to see what is going on. I checked the
> server logs and there are no error messages logged.
>
> One thing that I have noticed is that the relational service seems to
> stop responding first. Then the transactional service will
> eventually stop and we have to restart the box.
>
> I checked out the communication settings and the communication
> threads are set to 32 and have maxed out since the last reboot. I
> read in some of the other posts that the communication threads
> locking up may cause the services to stop responding.
>
> My questions:
>
> 1.) Has anyone had the experience where running out of communication
> threads killed your server?
> 2.) For a user base of approximately 300, is 32 enough or too many?
> 3.) Anyone else experience issues where the relational service will
> stop responding for no apparent reason?
> 4.) Since nothing is being written to the logs, is there a setting
> or task that I can implement to possibly catch the issue?
>
> Thanks in advance,
> Rob

Just let you guys know,

Out of the blue (restart of pervasive version 10) all my clients started throwing error 3103 at me. Server was up and running. Even the application was running fine when started on the server.

Looked in the pvsw.log and it reported port 3351 in use by another application.
Reserved this port as explained in the microsoft knowledgebase article http://support.microsoft.com/kb/812873
Restarted the server and everything is fine again. So problem solved!

Hope this helps out.