I have a client who has been randomly loosing a field delimiter periodically in his main data table. When we examine the data record directly through edit, we discover a missing field delimiter, and then all the fields are in the incorrect position from that point on.

We went through some of his records, selected one for delete, and then deleted it. Trouble is, we can perform the query again:

SELECT filename ] "9999"

and it "finds" the record, or at least the @ID, again.

I can't reliably get Query Table results, either.

Then I found out, this is being run on a Zip drive. I had him disable Write behind caching in My Computer, System, Diagnostics, Advanced, but that didn't seem to help.

Anybody else have a clue.

Paul

paul@samsnet.com

PS - Still no luck with the GPF on the other clients' system.

In the tests that I have run, turning off write behind caching on

a WIN95 machine does not turn off the cache for local drives that are not being shared.

You can verify whether the system is still caching by

running the WIN95 SYSMON.EXE program which

will allow you to view alot of the behind the scene operations

performed by WIN95. Select either FILE SYSTEM: WRITES/SEC or

FILE SYSTEM: BYTES WRITTEN/SEC. If you are doing a large write

to the disk, you will probably not see any activity when the write is actually being performed. this would indicate that caching is

still being performed and updates are not immediate.

However, my experience with caching has been more with GFE s and

not the random dropping of a single character. Is he running

the ZIP drive through the parallel port? If so, does the ZIP support

pass through printing? If so, can it be that somehow the character

is being sent thru to the printer rather than to the ZIP drive

as data?

At

Shortly after i purchased my ZIP drive, I got a serious data error on one of my disks that IMO was because of having a write cache enabled. I think what happened was that I swapped disks before the write had completed causing part of the FAT table from one disk to be written on the other disk. This made me lose the data on both disks. I think the newer drivers are smarter about detecting disk changes, but I've learned my lesson about caching ZIP disks and won't do it again.

Note that this is on a lower level than Arev concerns, so the problem will manifest itself not just with Arev but with other applications.

In hopes that RevG and ARev are alike in this manner, Rev has its own disk caching seperate from windows. Remeber, DOS application?

To disable it, enter the command:

SET-OPTIONS (W)

someplace, preferably in the LOGON process.

View this thread on the forum...