Web Site Login
^ November: PSQL on Mac? ^
October Results: Insufficient Data
[See All Surveys]
|
|
 |
Status 94 - Frequently Asked Questions
Last Updated: 07/28/2000
Status 94 is not a common error, but the question arises often enough to present this material in one location
to make it easier to troubleshoot. The information has been collected from many incidents over the years, and some
of them are included here in their entirety. As such, the document does not flow well, but it does provide a lot
of information. We will work to clean it up as time goes on....
What is Status 94?
The official definition of the Status 94 is "Permission Denied." This was originally designed to indicate
that the user tried to access a data file to which he or she does not have proper access. However, problems in
obtaining the proper network name and password from Windows workstations has increased the causes of the Status
94 message to a point where it can become annoying.
Btrieve error 94 usually indicates a problem with file rights. To troubleshoot this problem, determine whether
the user or program attempting to access the Btrieve data has the required rights for the database files being
used. If not, verify that the user has the relevant directory or file rights.
This FAQ is split into sections for the major server types, followed by standard troubleshooting suggestions.
All NetWare Servers
NetWare 4.x Servers
NetWare 5.x Servers
Windows NT Servers
General Troubleshooting Guidelines
All NetWare Servers
- Insufficient User Licenses for NetWare
User had a 20-user license of NetWare, and there were 20 people logged in! When the 21st user tried to log in,
it failed, but the user ignored the error and tried to continue anyway by logging into the application. When it
tried to access the files on the server which was not attached, it reported the status 94.
Resolution: Increase the user count of the server,or disconnect some users..
I have three workstations that have 95 "factory" installed and two workstations that were upgraded
from 3.1 to 95. The "factory" Win95 can access Btrieve files without an error. The "upgraded"
stations give an immediate status 94. User ID's appear not to matter. The network people tell me they are using
the Microsoft network client. The "factory" machines have Win95 version 4.00.950a. The upgrades had 4.00.950.
They installed SP1 to 95 and now the "upgraded" machines have 4.00.950a.
Resolution: Use a utility that shows what DLLs are in memory - something like MSInfo32 or BModules. Check the version
of NWNP32.DLL and verify that it is dated at least 7/11/1995.
- Btrieve 6.15.440 Used in Multiple Server Environments
Users are getting Btrieve status 94 error messages trying to access files on a remote server. The Windows Btrieve
requester prior to the 6.15.440 release did not properly handle the multiple server environment. The system was
trying to log into the remote server to verify access rights. However, it did NOT use the user name with which
the session was established. Instead, it used the user name from the primary connection. As a result, if you log
into the network as user BILL, then attach to another server as user DBASE (which has the proper access) and no
user BILL exists on the second server, you will not be able to access any files on the second server.
Resolution: Either create a user name on the second server which is identical to the first, or upgrade to at least
the 6.15.440 release of the requesters.
- Btrieve (Older than 6.15.440) Used Without Sufficient NetWare Connections
If you run under Novell with Limit Concurrent Connections set to Yes change Maximum Connections
to at least 2. This used to be a problem only in the 32-bit requesters, but the latest 16-bit requesters also see
this problem.
Note: This issue has been mostly resolved in Btrieve 6.15.445. The previous 32-bit requesters needed the user to
have two concurrent NetWare connections. One connection was used very briefly to authenticate the user, then it
was released. If the user did not have this NetWare resource, he would get a status 94 because we could not authenticate
them. The reason we used this method previously was that the calls to do it any other way did not exist. Anyway,
the 6.15.445 requesters can now authenticate the user with a single connection. However, if for some reason that
fails, we will revert to the previous two-connection method.
How is this implemented? The engine will obtain a list of network addresses of all workstations connected to the
server, and then find the connection that the user is logged in with by matching the workstation's network address
as passed in via the clientID. The only thing I can think of that might cause problems is if the workstation had
more that one NIC, and the workstation's network address that the requester obtained is not the same address as
what the server believes to be the workstation address. If the engine can not find the workstation's address in
the list, it will fall back to the pre-445 method and require two connections.
Resoltuion: Upgrade to 6.15.445 or higher requesters.
- Pervasive.SQL 7 Accessed from Citrix MetaFrame Servers
Users do not have unique identities through Citrix to NetWare. This usually resulted in a Status Code 94. The
algorithm has been changed so that it also tries to match the user name. However, if the user name is different
but the Network and Node ID is the same, it looks for any other connections. If there are any, then the user name
is required. This keeps the engine from granting access rights to everyone on the WinFrame server according to
that of the first user logged in.
Resolution: Upgrade to Pervasive.SQL 7 SP3 or later.
- Errors Accessing Files In Directories Containing Embedded Spaces
Accessing a local file with a local engine may return status 94 - the application encountered a permission error
- when the directory path contains a space. The space acts as a terminator to the filename, resulting in an incorrect
pathname going to the engine.
Resolution: Move the data to a directory path that does not use long file names with embedded spaces.
NetWare 4.x Servers
- Btrieve Requesters 6.15.435 on NetWare 4.1
With long paths (G:\IA\ALGEMEEN\MAXDB) I get Btrieve errror 12/94 on starting an application which uses Btrieve.
However all the files exist in the directory. With shorter paths (G:\IA\ALG\MAXDB) there is no problem. I am using
Windows 95 with the Microsoft NDS client in Bindery Emulation. Server software is NetWare 4.1 with PT7 applied.
Btrieve for NetWare is version 6.15.435. I am discovering the problem only with Thunk=Yes (Local=No, Requester=No).
With Thunk=No there is no problem.
Resolution: Upgrading the CLIB.NLM on the server resolved the problem.
- Btrieve Requesters 6.15.440 and Later
After installing the 6.15.440 patches for NetWare and using thunking with the older Server Engine (6.15.435),
I only get Error 94. We have seen this problem with the 6.15.440 and newer updates when used in an NDS environment,
and this is a known issue, primarily with the Microsoft network client software and the MS NDS Service. There is
a problem with the WBTRV32.DLL in this release (dated 2/12/97) which causes this status code.
Resolution: If you are using Btrieve in an NDS environment, replace the WBTRV32.DLL dated 2/12/97 with the file
from the 435 release (dated 11/7/96). A list of valid files which typically resolve this issue is shown below:
W16NR DLL 10,784 10-12-95 3:28p
W32BTICM DLL 42,496 02-13-97 1:15p
W32NR DLL 18,944 10-12-95 3:49p
WBT32RES DLL 4,290 10-10-96 10:02a
WBTICOMM DLL 41,980 01-30-97 2:45p
WBTRCALL DLL 43,472 02-04-97 1:59p
WBTRLOCL DLL 17,762 10-10-96 10:02a
WBTRTHNK DLL 5,824 07-15-96 10:43a
WBTRV32 DLL 62,464 06-09-96 12:21p
WBTRVRES DLL 4,192 04-19-95 3:16p
- Btrieve 6.15.445 and NetWare 4.x Servers
When using 32-bit requesters and when thunking from 16 to 32, the engine needs to authenticate the user by checking
existing NetWare connections. Btrieve 6.15.445 was accomplishing this authentication by comparing the requesting
client ID against the node addresses in the server's list of existing connections. If a match is found, this is
assumed to be the user's connection and the system checks that user's access rights for the requested operation
(e.g. creating or opening a file).
The problem is that NetWare 4.x servers sometimes create a second "utility" connection for NDS behind-the-scenes
tasks, tree browsing, etc. In NetWare Monitor, this will appear as a NOT-LOGGED-IN entry with the same node address
as the user connection. If the NetWare API call to locate the connection ID happens to return the NOT-LOGGED-IN
connection instead of the valid user connection, then Btrieve fails to properly authenticate the user and ultimately
returns a status 94.
Resolution: Upgrade to Btrieve 6.15.451 or later.
- Btrieve Requesters 6.15.430 on NetWare 4.1
I have a 16bit app running in Win95, with the Novell Client 32, and a NetWare 4.1 server. I have applied the
latest patch (dated 12/21/96) to the server and made sure that the requester DLL's on the workstation conform to
the specs outlined in the Btrieve and NDS document. The question is, must I have bindery emulation turned on at
the server for my application to run? I have tried it with the emulation turned on and it works with both a DOS
path and a UNC path. But, when I turn emulation off, I receive status 94 errors when I attempt to connect to the
server, no matter what I do.
Btrieve is trying to authenticate to verify user rights. It must have the bindery available to handle this. The
Btrieve engine does get added as an object to the NDS, however it's only a dummy object. So, from WIN95 workstation
you can login via NDS. However, on the server you do need to have bindery emulation on. .
Resolution: Enable Bindery Emulation and make sure the users are in the same container as the server where the
files are located.
- NetWare Servers Running Pervasive.SQL 7 over TCP
You may encounter Status Code 94, "Permission Error," on a Windows NT or Windows 95 workstation if
you attempt to use the Microsoft Client (Win32) for NetWare to connect to a NetWare Btrieve server using only TCP/IP.
The Microsoft Client for NetWare Networks (Windows 95) and the Client Service for NetWare (Windows NT) are not
supported by Pervasive when using TCP/IP and NDS login.
Resolution: There are four options. (1) Use the Novell IntraNetWare Client. (2) Make sure your user name and password
are identical on the client workstation and the server. (3) Use SPX instead of TCP/IP. (4) Using Setup, add a valid
user name and password to the Communications Requester "Runtime Server Support" option.
NetWare 5.x Servers
- Btrieve 6.15 on NetWare 5.x Servers with Service Pack 4
A site had upgraded NetWare to Service Pack 4 and sudden problems with Status 94 arose.
Resolution: Backing out NetWare 5 SP4 fixed this issue.
- In another case: Btrieve 6.15 on a NetWare 5 server with Service Pack 4.
I was getting a status 94 error message before I setup the bindery context on the new server. Everything was
working fine for a short while. Now, there are certain time when the users start getting status 94 error messages
again. But, if I give it some time, the error messages go away and things are back to normal. It's almost like
a DS synchronization problem, but I haven't seen any problems with that. I recently found out that it has something
to do with how the client connects to the server. If the client connects with IPX, then everything is ok. If the
client connects with IP, then I get Status 94 or very slow response.
Resolution: Unknown.
Windows NT Servers
- Windows NT Servers After Changing Access Rights
The most common problem with Windows NT Servers has to do with access rights for the SYSTEM user. The Btrieve
service utilizes the SYSTEM account, unless the service is explicitly assigned to another account. When people
start locking down and securing a Windows NT Server, they often remove the EVERYONE group from the list of users
with access to a database directory, then re-assign rights to a specific group of users. However, when this occurs,
the SYSTEM user is denied access, and status 94's result as soon as the system is restarted. (Why doesn't it happen
right away? The Windows NT SID is only generated at logon, and rights will not immediately change. This is different
from NetWare, where changes take effect immediately.)
Resolution: Fixing this is easy. Add "SYSTEM" to the users who have rights to the directory, being
sure to check the "Replace Permissions on Subdirectories" and "Replace permissions on Existing Files"
boxes are checked. Or, change the service to log in as a user in the proper access groups (or even as Administrator).
See the Microsoft documentation for NT on how to modify a service's login.
- Btrieve 6.15 on Windows NT due to WINS Problem
User at a distant site running Windows NT (accessing over a WAN link) is receiving Status 94 errors. The system
admin did a forced synchronization of the WINS database from the main site to the remote site. When this completed,
the system instantly started working again. Since the workstation requester is responsible for routing the request,
it was probably building the request (with the UNC pathname) and passing it to the wrong server (if the WINS database
provided an incorrect name resolution), which resulted in the status 94.
Resolution: Force WINS Synchronization.
- BREQNT.EXE Used With NetWare Runtime Server Support
The BREQNT.EXE DOS requester problem with accessing files on a Windows NT server when NetWare Runtime Server
Support was enabled (/c option) has been fixed. Previously, this requester was incorrectly returning status 94
(permission error).
Resolution: Upgrade to 6.15.445 or better.
- Accessing Files on Remote WinNT Server, then Local WinNT Server
From a Windows NT machine running Btrieve, first open a Btrieve file on a remote Windows NT Btrieve server;
then open a Btrieve file on the local Windows NT server. In previous releases, the second open would incorrectly
return a status 94 (permission error).
Resolution: Upgrade to 6.15.445 or better.
- Connecting via SPX to Windows NT Server Running Microsoft FPNW with Pervasive.SQL 7
You may encounter Status Code 94, "Permission Error," if you attempt to connect via SPX to a Pervasive.SQL
server running on a Windows NT server with Microsoft File and Print Services for NetWare (FPNW) installed.
Resolution: For Btrieve clients, use the Novell IntraNetWare client to connect to Btrieve servers on FPNW.
General Troubleshooting Guidelines
This information was provided by Pervasive in the STATUS94.DOC file.
Status Code 94 occurs when permission is denied to the files being accessed across the network.
The fastest and easiest way to troubleshoot Status Code 94 is to isolate the cause. This can usually be done by
process of elimination.
Start by testing and asking a few simple questions like:
*"Does it occur for every user?,"
*"Does it occur on every workstation?," and
*"Does it occur for every user on every workstation?"
Because the Status Code 94 is a permission error, questions like these will quickly narrow down the cause. If certain
users get the error on any workstation, that indicates those users permissions or network attributes are the cause.
If one or only a few workstations are getting the error, then that leans towards configuration or components specific
to those workstations. If the problem occurs for every user on every workstation, that indicates the problem is
most likely at the server level. With this in mind, review the information below to assist in resolving Status
Code 94 errors:
Network Attributes
Regardless of operating systems involved, the following guidelines apply:
* Logins should be synchronized to determine if they are the cause.
Any given user's login should have the same user name and password for ALL servers and the workstation operating
system. This user name should NOT be "Admin" or "Supervisor," and the password should not be
left blank. Once this is done, you have eliminated the login as causing the Status Code 94.
*The User must have a minimum of read/write access to the directories where the files being accessed reside. Files
being accessed must be flagged for read/write access. Once these two things are done and verified, you have eliminated
network rights as being the problem for Status Code 94.
Workstation Attributes
If any user gets Status Code 94 on one or a few workstations and those same users do not get the error on other
workstations, that indicates that a component (.DLL or .EXE) may be incorrect. To correct this, look at the components
on the workstation that does not get the Status Code 94 and compare them to the ones that do. If any differences
are found, make the system getting the error match the system that does not get the error. Pervasive Software has
tools available to assist with component identification. You can obtain these tools by downloading them off of
ftp.pervasive.com or by contacting Pervasive Support.
For 32-bit operating systems, check to see if both 16- and 32-bit requesters receive the error. If one does and
the other does not, this is a good indication that components or settings are causing the error. Try adjusting
the 'thunk' yes/no setting in BTI.INI or the registry (changing it to the opposite of what it is currently set
to).
Also, you may need to download or obtain the component identification tools as stated in the previous paragraph.
NT Server Specifics
Pervasive products run as 'services' under NT. By default, these services use the 'System' user. So, in addition
to the network users having permission to the directories where the files being accessed reside, the 'System' user
must also have 'full control' permissions. When installing NT, you have the option to give the 'System' user rights
automatically to all files or have the administrator specify them. You should consult your NT documentation for
specifics on the 'System' user. However, if 'System' does not have permissions under NT, the server returns a Status
Code 94.
NT has a utility called Security Auditing that may be useful if the server is suspected as being the cause of returning
Status Code 94. Both users and/or directories can be audited. The audits can them be reviewed and should provide
information on what permissions need to be adjusted to resolve Status Code 94.
To Audit:
1. Go to User Manager for Domains in the Administrators Tools group. Under Policies, select Auditing, then select
Audit These Events, then select the check boxes:
File & Object Access
Use of User Rights
2. Exit User Manager; run File Manager. Select the directory that Btrieve is trying to access (the directory you
think you're getting permission errors on). Then go to the Security Menu, select Auditing, then click the add button,
then select the "Everyone" group and click add, then ok. Then check the boxes for Replace Auditing on
Existing Subdirectories and Replace Auditing on Existing Files. In the lower check boxes, check the following:
Read Success Failure
Write Success Failure
Execute Success Failure
3. Click OK, exit, log off, re-logon and tell the cust to do whatever it was he was doing when he got the error.
When they get the error, go into the Event Viewer, select Security from the file menu, and see what it says. You
should be able to figure out the problem from there.
Theory: In this case, NT will log successful or failed file or directory accesses, and list the reason for success
or failure. Look at the reason and go from there!
NetWare (NDS) Specifics
NDS (NetWare Directory Services) has been determined to cause Status Code 94 in numerous cases. This has normally
been attributed to the bindery context or containers being incorrect. Here are the general guidelines for the users
and products in an NDS setting:
1: The bindery context on the server where Btrieve is running MUST have a Read/Write replica of the partition of
the container object for which the bindery context is set.
2: The user (or alias) MUST exist in the container object for which the bindery context is set.
3: The Btrieve object must exist. This can be accomplished using the Btrieve Setup Utility (BSETUP.NLM), which
adds a LOAD BDIRECT line to the BSTART.NCF.
4. The bindery context should be set to what it was when the users and objects were added. If the bindery context
changes, the users and objects may need to be removed and added again under the new context.
Consult your NetWare documentation for specifics on NDS settings.
Here's some info recently provided by Pervasive:
Are you opening a file within the default NDS context? What is the WS platform and network client? You might try
setting the default context for the WS to be the same as your target for the file open. The connection box should
work for the NetWare Client32 version 2.2. The 2.5 version has a new icon (lower right / task bar) and default
connection panel. WHOAMI from the Network Neighborhood will show the current default context. Check to see if the
user is in the same context as the engine.
Pervasive.SQL Benefits
By adding support for the Novell 32 bit clients, the vast majority of the status 94's seen with 6.15 can be
eliminated. This is because the P.SQL requesters now support the Novell API's that allow it to determine a user's
proper access rights before sending the Open or Create call to the engine, and no longer need to rely solely on
RTSS. It is important to note that running 32 bit applications (or thunking to the 32 bit requester) on Windows
NT with only the Microsoft Client for NetWare installed still relies on RTSS in the P.SQL release. Thus, the same
caveats and Bindery Context requirements for the v6.15.445 patch update apply to the P.SQL release. The additional
caveat is that using TCP/IP as the transport to a NetWare server prevents the Btrieve engine from comparing the
workstation's network (SPX) address against the network addresses of all users logged into the target NetWare server.
Thus, using TCP/IP in conjunction with the Microsoft Client for NetWare from a Windows NT 4.0 workstation will
still be problematic. The recommended solution is to use the Novell IntranetWare Client for Windows NT.
In most cases, this becomes the best solution for Status 94 problems on NetWare -- simply upgrade the client
components to a 7.x client, and the problems go away! This is often much cheaper than trying to figure out what
else is broken.
If you still can't get it to work, contact Goldstar Software and let us work with
you to help! |
|
|