Hi Steve,

First, I know that I wouldn't rate something as "Disagree..." if *I* thought it was not feasible. I'd write a comment to the wisher and I'd withold my rating pending a reply.

Now, as to the question of feasibility...

Since the PC was invented things sure have gotten a whole lot more complicated, that's for sure. But the basics of computing, and especially the accuracy and integrity of processed data, has remained a constant throughout. That is to say, the people dependent on a computing service of any kind expect that their data will be held with unfailing accuracy once the system "acknowledges" that it has accepted their data.
That is why we have error routines - to inform a user when something goes awry and possibly permit them some options on how to handle the situation.

Now look at a VFP FLUSH of a VFP record as nothing different than any other write of any other data by any other system, because all that FLUSH says is 'do it right now so that I can be sure you've got it'.
**IF** a recordset sent back to SQL Server got jumbled or a Word document was only half-sent before some error condition arose, you'd of course expect something in the system to handle it. And indeed, by and large, there is code all over the place to do that, in the form of error detection/correction routines. It doesn't matter (or at least it shouldn't, but maybe MS OS current practises do make it matter) if the data in question bounces off three satellites and passes through China and East Timor between leaving a workstation and arriving at the file server in that, if it ain't 'whole' when it arrives, then notification to the originator is required if it cannot be fixed by the error routines in the OS and hardwares along the way.

And when I send something to the UT (like this message) all of the complexities in between still keep intact that the response back (message saved) is for me and not just for any ol person logged in at UT at the same time as me. If it can do it there, it can surely do it for any workstation interacting directly with a file server.
Since the physical I/O actually happens on the file server, using the server's I/O routines, it is incumbent on those routines to keep the requester 'informed' of the success or failure of the operation and it is incumbent on the workstation's OS to wait for that confirmation/error-report OR 'assume' a failure if the return doesn't happen within time or activity threshholds.

If modern computing has reached the point that data integrity is wholly dependent on running only on a centralized processor, then we had better go back to mainframes.

cheers


>Hello Jim,
>
>I was not the one who made that rating, but I can see some possible reasons as to why your idea may not be feasible:
>
>1) VFP (by itself) is not a client/server (I know you know this); the server is in charge of when the bits actually hit the physical media...what if this is several seconds? Or longer? The application would have to wait for that. As it stands, the flush should (I have not tested this) be helpful in situations where the workstation gets disconnected, locked up, loses power, or whatever, after the flush. The server should have an UPS, and is much less likely to have these problems occur.
>
>2) How would server communicate this information back to VFP on the workstation? Keep in mind that the data may be sitting server running W2K, NT, Novell, Linux Samba, and so on...
>
>Just some quick thoughts,
>
>steve
>
>>The Wish #1146 (yes, it is one that I wrote) this morning was rated as "Disagree - I see no need for this" by someone.
>>
>< snip >
>>I could (possibly) understand someone rating it as "Helpful - not a big issue for me" but I am curious at the kind of rationale that would have someone rate it as an outright "Disagree - I see no need for this".
>>
>>Any opinions?