Re: NETWARE 4.11 and PARADOX-DATABASE

From           "Kevin D. Snodgrass" <kdsnodgrass@earthlink.net>
Organization   There is no organization here, only chaos.
Date           Mon, 13 Sep 1999 18:17:36 GMT
Newsgroups     comp.os.netware.misc
Message-ID     <37DD3FCF.ED9DCC24@earthlink.net>
References     1

Die Webnase wrote:
> 
> Hi, we have a NW 4.11 Server and a Paradox-database-Software. Recently with
> no reason tables currupted. The Software-Developer say that Netware may be
> responsible. Other clients use WIN NT with no such problems. Does anybody
> know about database-problems with Netware? And haw to avoid them? Thanks for
> a hint.
> regards
> Frank

<ding>

I have fairly extensive experience with xBase apps and
NetWare and have encountered a problem with the combination
of xBase app and Client32.  I'll try to explain what
happens.

Most xBase programming systems (both libraries for general
purpose programming languages like C/C++ and integrated RAD
types systems like Clipper, FoxPro, etc...) do not use the
correct DOS file/record locking procedures for networked
environments.  Clipper specifically (and maybe others) do a
convoluted scheme of creating a lock record in the database
or index file at a huge offset, like record # (1 billion +
real record number).

The proper method of file/record locking, implimented in
MS-DOS 3.1 along with file handles, is to call INT21h, 5Ch
(AH=5Ch; AL=00h to lock, =01H to unlock; BX=file handle;
CX:DX=4-byte starting offset from beginning of file of
region to lock; SI:DI=4-byte integer, high/low size of
region to lock, in bytes).  I have confirmed that some
versions of Clipper, DBase, FoxPro and CodeBase do not do
this.

Novell's Client 32 impliments a local cache of network
writes.  That is, all data written to the network is cached
locally on the workstation and sent out the wire as time and
network availability allows, freeing up the workstation to
continue working.  This works great when you are saving your
Word or Excel file, not when using legacy DOS database apps
with networking and multi-user access kludged in.

Combining the two prevents the record locking used by
some/all xBase apps to be written to the network drive
immediately, but the app on the workstation thinks it is OK
so it continues.

DO NOT BLAME NOVELL FOR THIS!!  If the writers of the xBase
APIs would have written them correctly, using DOS INT21h,
5Ch, this would not be problem since the lock call is not
cached by Client 32.  Client 32 cannot determine that a file
write to a huge record number is actually the kludge for
multi-user network access, it is just a write to file at
offset.

To prevent database corruption you MUST disable workstation
caching in Client 32.  Set CACHE WRITES=OFF and FILE CACHE
LEVEL=0.

Some companies will recommend setting TRUE COMMIT=ON.  This
is generally not needed (although it will pretty much
guarantee no database corruption).  TRUE COMMIT causes the
DOS call to write data to a file to block until a success or
fail is returned from the fileserver on it committing the
data to disk.  This bypasses the NetWare server caching,
which is entirely unnecessary for THIS problem.  Only after
the fileserver has written and verified the data has been
written (or cannot be written) to disk will it send a
success back to the workstation, which then unblocks the DOS
write to disk call and the workstation can continue.  This
can cause extremely poor response for the users, especially
on busy networks.


-- 
Kevin D. Snodgrass

I no longer use earthlink.net,
    replace with home.com or yahoo.com.