>We created an application in VFP 5.0a using Visual Maxframe on Novell 4.11 with 50 users. The highest activity files are 80,000+ records and are experiencing the problem. The first field in each of these tables is not necessarily a primary key, but it is an integer. Occasionally (2-8 times per week), the 2nd or 3rd or 4th byte of that field gets overwritten with CHR(26). This is the CTRL+Z character. This changes the integer to a new number! When we look at the index for this field, the index still references the original number. (the data changed without the index) We have determined that this is not happening when the record is added, but later on. The higher the activity on the network or application, the more corruption we experience.
>
>We have located one other user on this forum with this problem (see thread #122286). The only common factors between us are VFP5.0a and Visual Maxframe. (networks differ, etc)
>
>Is anyone else having this problem?
>Rob, Mark, Jamie, Jeanne

We are experiencing the same problem running under NT4 on a Novell 4.11 network using the Intranetware Client 4.30. I had our network engineering group contact MS through our Premier support option. Here is what we got back from them.

=================================================================
We have received one report of the error in question and reproduced it only
on Win95 OEM Service Release 2. Despite our best efforts, we have never
reproduced it in any other operating environment. As a workaround, this
specific customer was able to add an integer field as the first field in
their table and has had no problems with the application. We believe this to
be an operating system issue addressed by an OSR2 patch described in the
following article:

====== start of pasted article text ======
Possible Database File Damage When Data Is Appended [win95x]
ID: Q174371 CREATED: 26-SEP-1997 MODIFIED: 07-OCT-1998
95
---------------------------------------------------------------------
The information in this article applies to:

- Microsoft Windows 95 OEM Service Release versions 2, 2.1
---------------------------------------------------------------------

SYMPTOMS
========

Database programs running in Windows 95 OEM Service Release 2 (OSR2) or
2.1 (OSR 2.1) over a Microsoft network may damage the database.

CAUSE
=====

When a program uses the GetFileSize() API to get the size of an existing
file on a Microsoft networking server (such as a Windows NT-based server),
the Client for Microsoft Networks may not return the correct file size.
When the program then attempts to write additional information to the end
of the file, it may overwrite existing data instead.

This problem has been observed only with the version of the Client for
Microsoft Networks (Vredir.vxd) included with OSR2 (version 4.00.1111) and
later.

STATUS
======

This issue is resolved by the following updated file for Windows 95 OSR2:

Vredir.vxd version 4.00.1116 (dated 9/11/97) and later

To install this update, follow these steps:

1. Download the Vrdrupd.exe file from the Microsoft Software Library
to an empty folder.

2. In My Computer or Windows Explorer, double-click the Vrdrupd.exe file
you downloaded in step 1.

3. Follow the instructions on the screen.

The following file is available for download from the Microsoft
Software Library:

~ Vrdrupd.exe

For more information about downloading files from the Microsoft Software
Library, please see the following article in the Microsoft Knowledge Base:

ARTICLE-ID: Q119591
TITLE : How to Obtain Microsoft Support Files from Online Services

The following files are installed by Vrdrupd.exe:

File name Version Date/Time Size Destination folder
---------------------------------------------------------------------
Vredir.vxd 4.00.1116 9/11/97 11:16a 156,773 Windows\System
Vnetsup.vxd 4.00.1112 5/30/97 11:12a 17,595 Windows\System

MORE INFORMATION
================

For additional information about issues resolved by updates to this
component, please see the following articles in the Microsoft
Knowledge Base:

ARTICLE-ID: Q172594
TITLE : Cannot Connect to Server with 15 Characters and Period
in Name

ARTICLE-ID: Q165402
TITLE : Windows 95 Update to Encrypt Passwords in Memory

ARTICLE-ID: Q161100
TITLE : File May Be Truncated When Copied to a Full Network Drive

ARTICLE-ID: Q157114
TITLE : "Access Denied" Attempting to Run File on LM/X Server

ARTICLE-ID: Q156497
TITLE : Duplicate Print Output on PC-LAN Server from Windows 95
Client

ARTICLE-ID: Q152186
TITLE : Possible Network Data Corruption If Locking Not Used

ARTICLE-ID: Q148367
TITLE : Possible Network File Corruption with Redirector
Caching

ARTICLE-ID: Q142803
TITLE : Hang or Locking Error Accessing Database Files Over Network

ARTICLE-ID: Q140558
TITLE : Deleting Files on Samba Servers May Delete Local Files
Instead

ARTICLE-ID: Q138249
TITLE : Updated Vredir.vxd Corrects Errors Running Files on LMX

ARTICLE-ID: Q160807
TITLE : Cannot Connect to Windows NT Server with Many Shares

ARTICLE-ID: Q150215
TITLE : Disabling Automatic Network Shortcut Resolution

ARTICLE-ID: Q138014
TITLE : File May Be Truncated to Zero Bytes When Copied Onto Itself

ARTICLE-ID: Q136834
TITLE : Error Copying Read-Only Files to Core SMB Server

Additional query words: corrupt

====== end of pasted article text ======

Apparently, when an OSR2 client attempts to extend the file, when a user
adds data, FoxPro correctly calls GetFileSize() to determine the file's
size. GetFileSize() returns an incorrect value, and FoxPro extends the file
incorrectly. The solution is an update to the OSR2 redirector. The customer
who reported the original problem has been contacted with this information.
I am not sure of the outcome of his testing. Our testing group could not
repro the problem after application of the VREDIR patch.

I hope this information is helpful.

Brian W. Nash
Microsoft Developer Support
briann@microsoft.com
=================================================================