>Pffff me too, Peter. That printed out to 11 pages!!!
>I chose to not duplicate all that stuff here < s >.
>
>1) Writing of RLOCK()ed records.
>We were talking about non-transaction processing I thought, and in this case (only) I feel that it would be safe for VFP to write such records before they are UNlocked.
>HOWEVER, I agree that it doesn't seem to, and that it certainly couldn't in buffered/transactional situations.

I agree Jim, the transactional environment wasn't defined. But, just because of this, implicit transactions are the case, just because they just are. You can't stop them, not even with remote vieuws. Thus, supposed another could approach your RV with its updates in there at locked records, another won't see them until you Unlock them. Note : this is theory only, but it should be applicable.

>
>2) "Forcing" a re-read.
>I suppose that a RLOCK() does force a re-read of data from the disk.
>But it is my experience that a simple GO does too (at least on a table opened SHARED).

As what I saw on the sniffer (and btw already knew), no, this does not cause an re-read. However, if you -by accident- GO to a record which wasn't in your cache, obviously it will (re-)read. The whole point from off yesterday is now, that you can't control what's in your cache. So again, if you were fastly reading records up to some records before the one you want to GO to later, it will be in the cache already. If you then GO to it some 10 secs later, and another applied a write to that record (and Unlocked), you will still have the old version from your cache. An RLock always does the trick.

>
>3) FLUSH command
>We really need much more detail as to how this command works - what it really does to what, when, under what circumstances!
>I have mentioned this in a thread in the VFP Documentation section here on UT.
>
>4) SET REFRESH
>We also need more details of how this works, when, and on which data.
>
>5) VFP locking (and unlock) mechanism
>Jim Booth provided some clarification on this and as I understood it. . .
>a) Yes, VFP does use an OS (file system?) facility to accomplish this;
>b) It is in actuality a 'semaphore' system unique to VFP and consistent across all versions of FP/VFP. Other (application) systems may use the same facility for similar purposes but theirs too would be unique to themselves.
>--- It doesn't matter if any record is identified there by its actual physical location or whatever, but only that ALL FP/VFP versions use the EXACT SAME value to refer to the same record and that no two records can have the same value.
>--- I liken this to the IBM mainframe's ENQ/DEQ system if you have any familiarity with that.

Not familiar with that.
What I personally don't understand with the semaphore system, is why the bytes locked have to be beyond (the records of) the file itself. But I don't find it importand to understand it.

>
>You newest observations
>
>We have arrived at a point where it is CLEAR that we do not have enough information, at none of the hardware, OS, file system itself or VFP levels, to come to a sensible conclusion.
>I endorse your hint that people who have such knowledge would be awfully helpful here and I think that information could be provided that doesn't disclose patented stuff.

So ? nobody there ? nobody likes ? nobody can't afterall ?

>
>At the least it would be most instructive if the Command Reference documentation would note the relationship of each DML command to physical I/O performed.
>For instance:
>--- In the GO, GOTO, n documentation: This command causes the record on disk to be (re)fetched except when buffering is in effect and that record has already been modified.
>--- RLOCK() documentation: This command (i) obtains a fresh copy of the record from disk unless buffering is in effect and that record has already been modified, (ii) keeps the record in storage without re-write until it is unlocked.
>--- REPLACE documentation: .....
>--- etc. for all I/O commands

Yea, very strange that up till now we always have to make guesses about this. So this would be VERY good.

>
>I am astounded that your "sniffing" shows that only records are transferred from the file system to VFP (server to workstation) on a read.

I'm glad that I am not alone then.

It would be very useful to learn what is actually read/(re)written on a physical I/O. We assume it is a cluster, but who knows??? Maybe the hardware is now capable of reliably writing only specific bytes.
>I am not so sure that "troubleshooting whatever corruption situation will be the vast impossible job" because writing is no doubt different than reading.
>As long as VFP properly tracks the records that it has requested, and the actions against them and the additional copies of them that it manages in storage, then it is what it writes that is really of interest. I would guess (what's new by now?!?!) that there is most likely data requested regarding the "lock semaphores" (file system to workstation) before writes are actually specified in order to accomplish the 'merging' that we both talk about.

The only thing I can tell right now is
a. I did not sniff the writes yet;
b. I can expect that VFP does nothing more that giving a bytestream and offset for write just as well. Why ? because I found that within a corrupted records normal data can exist, and this 100 % matches what the app did (write one or two fields only). One thing though : I didn't prove that the record fetched arrived at VFP with nulls. If that is the case, the whole record could have been written back, only the replaced fields causing not-null areas within the record.
So three options altogether :
1. At a write first some whole block (cluster) is fetched and merging takes place.
2. At a write the whole record is send and merging takes place somewhere in the file system
3. At a write only the relaced fields are written. Note that this hardly encourages for merging, because this would be very simple. For sure if the physical I/O can be at the byte level.

>
>You are certain - and your description makes me agree - that it is in Novell that the corruption is happening in your observations of THIS problem. The only sensitivity that comes to mind as relates to your problem is when a VFP record itself EXACTLY fits the Novell cluster and the EOF marker must go to the next cluster. Yet if that was a problem it would occur every "n" cases in any file (depending on actaul metrics) and then only if clusters are always filled to the maximum.

I didn't find any clue on this, and was explicitly looking for it. However, what I did find, was just too many situations where the Deleted Mark (2Ah) was the only corrupted byte in a record. Added with the info that I seem to recognize "deletes" to be around the corruputions always, I expect no coincidence here. And mind you, the Deleted mark/byte will replace the EOF mark at the append of a new record ...

>
>I take it that there is no commonality of HD types (brand and size and on-board cache) or HD adapter brand/model.

Can hardly be the case, since so many replacements have been done, including our own replacement of some 5 servers during the traject, including changing from Raid5 to Raid1. Though I really never examined it, it would be a very high coincidence if in all cases the HD's were the same.
And under NT Server it won't happen ...

>
>good luck my friend

No problem. We'll come to it one day.