Database Error: 3014 or Database Create Error 3014
Applies to All NEO Products
Problem NEO reports a Database Error 3014 and will not start. Pervasive refers to this as encountering a 'Status 3014'.
Description This is an uncommon problem that confronts new users trying to start NEO for the first time and is related to a Pervasive conflict, setup or configuration problem. When you receive a Database (Create) Error 3014 in a NEO dialog box, the application cannot open. If you have the full Pervasive client on your workstation, the cause is that the Pervasive setting for the LOCAL MicroKernel Router is set to OFF. This setting defaults to ON when you install Pervasive SQL but can be re-reset at the workstation. In effect, the Pervasive router can not be found when it is loaded locally, since Pervasive is only looking on network drives.
Resolution 1 To resolve this, follow these steps from the desktop:
Click START | Programs | Pervasive SQL7 | Setup (WIN32). Pervasive SQL7 should be replaced by whatever version of Pervasive that you might be using. This brings up a pervasive settings window with 3 major sections: COMPONENT, CATEGORIES and SETTINGS.
In the COMPONENTS section, select MICROKERNEL ROUTER (WIN32)
In the SETTINGS section, select LOCAL and select ON in the radio buttons provided.
Click the SAVE button, close the windows to return to the desktop
Reboot the workstation.
NEO should now be able to use the LOCAL Pervasive functions, build and update its Catalogs normally.
Resolution 2, from the Pervasive Knowledge Base Troubleshooting a status 3014
Problem 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
Problem Environment: Pervasive.SQL 2000
Solution: Some of the strategies implemented to solve a status 3014 are:
Increased the number of maxclients. Rebooted NetWare server so that the new product was running. The new Pervasive.SQL 2000 requesters were being used against an old 6x engine. Turned multihome setting to YES. Pinging the server by name returned one IP address and Scout returned another. Upgraded to the Pervasive.SQL 7 product to the Pervasive.SQL 2000. The problem was happened when using Pervasive.SQL 7 client on Microsoft Terminal Server. Hardcode the Listen IP Address using the configuration utility. 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 . HOST files was edited to reflect the IP address returned when Server was pinged by name. Application was storing filename in the wrong parameter. Remapped the drives. UNC path was functional, but paths using drive letters failed. 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.