We have a Windows NT4 server running Pervasive 2000i SP4. This has
been working fine until we installed the latest Microsoft Series of
updates. Since putting these on we have been getting 3014 errors when
trying to connect to the server.

Is this just a coincidence, or is it me?

Here's some suggestions. However, I'd first check that you can PING the
server reliably by name. If not, then you have some sort of name
resolution problem, and this must be fixed first.
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 3014
Environment: Pervasive.SQL 2000
Description: Status 3014 after 16th person logs on.
Status 3014 connecting from a client to a server.
Status 3014 during the install and also when running the application.
Windows application getting 3014 and DOS application getting a 3016.
Status 3014: The MicroKernel router cannot find an engine

Solution: Some of the strategies implemented to solve a status 3014 are:
1. Increased the number of maxclients.
2. Rebooted NetWare server so that the new product was running. The new
Pervasive.SQL 2000 requesters were being used against an old 6x engine.
3. Turned multihome setting to YES. Pinging the server by name
returned one IP address and Scout returned another.
4. Upgraded to the Pervasive.SQL 7 product to the Pervasive.SQL 2000.
The problem happened when using Pervasive.SQL 7 client on Microsoft
Terminal Server.
5. Hardcoded the Listen IP Address using the configuration utility.
6. Local or Requester were set to NO and it needed to be set to YES.
This is based on the location of the files, engines available, and the
application.
7. HOST files was edited to reflect the IP address returned when Server
was pinged by Name.
8. Application was storing filename in the wrong parameter.
9. Remapped the drives. UNC path was functional, but paths using drive
letters failed.
10. Checked the selected protocol. One machine had only NetBios selected
as the protocol. Changing to TCP/IP solved the problem.
NOTE: These suggestions were gathered from customer interactions, and
may not apply to your particular situation.

Ian Wilkinson wrote:

Before getting too carried away on the client side.
Is there anything logged in the pvsw.log on the server?
Go to www.sysinternals.com and grab their TCPMON utility.
Not only will it tell you if something is listening on port 1583 and
3351, but it will tell you what application it is.
Is it listening and if so it is the database engine?

Leonard

On 16 Feb 2004 03:34:38 -0800, Ian (AT) Cognitosoftware (DOT) co.uk (Ian
Wilkinson) wrote: