I had posted concerning this problem towards the end of July. We were experiencing severe index corruption of FoxPro 2.6 indexes in a Novell environment. Here is an update to our situation.

The key elements of our system are as follows:
Server is a Compaq Proliant 300 dual 300 mhz pentium raid 5 with 3 9gb drives 128 meg ram.
OS NetWare Version 4.11 service patch 6
Workstations all are P75 and above running Win95 Client 32 (Version 2.2 at the onset)

We have implemented the following steps on 8/06 to solve the problem.

1) Cleanup autoexec.ncf

2) Check operational status of all componants in server (during this process we discovered an improperly initialized (second) NIC in the server. This NIC was disabled.)

3) Upgrade the Client 32 on all workstations to version 3.1.0.1 service release 1 with the following configuration settings changed from default in the advanced settings section.
Cache Writes = OFF
File Cache Level = 0
True Committ = ON
Use Extended File Handles = ON

(Note: Our application opens an extensive number of files, lots of Fox tables and we use DDE, WORD and a vast array of templates to produce documents. In a posting we received, it was learned that 16 bit applications which employ DOS based methodology (ie FoxPro 2.6) to open and close files have problems with Client 32. If over 170 filehandles are opened at the OS level, Novell will not properly track those over 170 and will not properly close these files IF THE USE EXTENDED FILE HANDLES IS OFF)

4) We rebuild all indexes weekly and check tables for corruption.

Our index corruption problems were radically diminished after these steps were taken.

We continue to have problems however. We are finding random bits of binary data in our tables. There is no real consistancy to the distribution of this data, the most heavily used tables are more likely to be effected, however not always.

Please any additional ideas or suggestions will be greatly appreciated.

Thanks, Jack
jfordyce@mako.com