Accessing Data on NetWare using Workgroup Engine

---

Accessing remote data on a Novell NetWare server using a Workgroup engine running on a Windows workstation presents a special challenge because every NetWare server has some version of Btrieve or Pervasive.SQL server running on it already.

Without taking special steps, any attempt to use a Workgroup engine to access data on a NetWare server may result in one of the following errors:

• Status Code 116: The file is owned by another Microkernel engine acting as a Gateway
• Status Code 85: The file is locked
• Status Code 12: The Microkernel cannot find the specified file.

The Best Choice

The most reliable, lowest maintenance, and fastest way to resolve this issue is to access the data using the server engine running on the NetWare server. Using the existing server engine is likely to save you many headaches in the future. You may need to purchase an additional user count license for the server, because it normally has only 2 permanent user licenses available, and these are used by NetWare itself. Before choosing to use Workgroup engines instead of the server engine, you should carefully evaluate your situation to make certain that you are unable or unwilling to make use of the NetWare server engine.

Using the Workgroup Engine

If you cannot use the server engine given your particular scenario, then the only way to make sure that Workgroup engines can access the remote data files successfully is to write the NetWare server into the Gateway Durability registry key located on all workstations that have Workgroup engines expected to access the remote data. By making each Workgroup engine believe that there is no server engine running on the remote server, you can provide access to the data files on the server. The Registry key information is provided below. You must substitute the actual name of your NetWare server for "myserver":

[HKEY_LOCAL_MACHINE\Software\Pervasive Software\Microkernel Router\Version 8\Settings] 
"Gateway Durability"="yes" 
"NumServNotRunning"=dword:00000001 
"ServNotRunning0"="myserver" 

Isn't there Another Way?

Simply turning on the Gateway Durability feature does not achieve the same purpose, because a server engine is in fact running on the NetWare server, so it will not be added to the saved list of computers where no database engine is available.

You cannot solve this problem by creating a permanent gateway locator file in the directory where the data resides. The server engine does not recognize gateway locator files, so it will take ownership of those files if given the chance, and thus prevent any Workgroup engine from acting as a Gateway engine.

In addition, you cannot solve this problem by setting the client configuration setting Use Remote MicroKernel Engine to Off at each workstation. Any Workgroup engine that happens to have this setting turned On will cause problems. If this "On" engine is the first to access the data, it will connect to the NetWare server engine, locking out all other workstations that have this setting turned Off. The other workstations receive status 12 or 116. If this "On" engine is not the first to connect, then the server engine will not be able to open the files, returning status 85 to this "On" engine. Finally, if all workstations have Use Remote MicroKernel Engine set to Off, then none of them will be able to connect to whatever computer is eventually established as the Gateway engine.

Manually editing the Registry is the only sure way to access data on a NetWare server without using the Pervasive.SQL server engine on that computer.