VERSIONS: All versions
SUBJECT: Access to Pdoxusrs.net slow on Novell network
BY: DARRAGH QUINN
Date: 9 August 2000
People have experienced difficulties using the Netware client. If that's what you're using then the following may be of interest.
From a Novell document:
Paradox uses a file called Pdoxusrs.net to control the number of allowed concurrent users per the Paradox license count. This file lists each
potential license connection, and tracks which licenses are available for use. A sniffer trace showed that the customer's Client32 workstation
accesses the Pdoxusrs.net file, and requests a connection. The server responds and the file shows that the first license connection is not available.
Client32 again asks for a connection, and the server responds that connection 2 is unavailable. This goes back and forth until an available
connection is found -- often 80 or 90 connections down the list. This sequence takes 7-10 seconds, during which time users get impatient and
reboot. This corrupts the Paradox database.
Solutions
Initially users were experiencing delays of 30 seconds when opening paradox. He has reduced this delay to 7-10 seconds by adjusting the
following "advanced setting" parameters under the properties of the NetWare client.
- Open control panel, network.
- Select the NetWare client, and choose properties.
- Choose the advanced settings tab.
- Cache writes = off, Close Behind Ticks=0, File Caching=0, Lock Delay=1, Lock Retries=1, Read Only Compatibility= on, True Commit=On,
Opportunistic Locking=off (with the older client)
VERSIONS: All versions
SUBJECT: Novell Netware 6
BY: LIZ < lizATparadoxcommunity.com >
Date: 21 January 2005
With Netware 6, Novell decided to change the default setting for Opportunistic locking. It used to be off by default. Now it is on by default.
VERSIONS: All
SUBJECT: Transaction Tracking System (TTS) on Novell Netware.
BY: LARRY DIGIOVANNI
Date: 22 April 2005
Transaction Tracking System (TTS)
A NetWare feature that protects database applications from corruption by backing out of incomplete transactions. Incomplete transactions are
sometimes the result of failure in a network component.
TTS tracks transactions on a per file basis. Since with Paradox tables, a single transaction impacts multiple files, TTS is absolutely no help. In
TID 671840 of the knowledgebase, Novell states that
Paradox products do not run well with TTS enabled.
This can cause a problem if it's watching net and lock files. Particularly under concurrent access. I'd expect if TTS had to back out a
transaction to one it would screw it up.
I believe you can (and should) disable TTS on a per directory basis. If not, you should disable it on the volume where Paradox objects
live.
FWIW, you should also flag any directory with Paradox tables and the .NET directory as "Purgeable", which prevents Netware from tracking
all deleted files in that directory. In some cases, you wind up tracking a thousand versions of the .LCK file.
Also, back in the day, we'd dedicate Netware volumes to Paradox (or Access, xBase, etc) and build the volume with a large block size. This
improves Netware's file management and reduces slack space on the drive.
If you get abnormal corruption, you should kill TTS and flag your Paradox directories purgeable. It may not resolve this problem, but
shouldn't hurt.
A quick Googling suggests that the TTS requirement for eDirectory went away with 8.5 or 8.6.