Hi, Terry.

>But, in fact, the notion of persistence is an illusion. Why should a connection be maintained after the last packet was sent or received? So, perhaps 'persistence' is less of a continuous handshake, and more of an eloquent bookkeeping scheme that allows the connection to appear continuous. Perhaps a robust client/server app is [really] dropping and restablishing connections all the time, and the only thing that persists is the client (or server) reference to that connection [object]. It makes more since that so-called robust client/server implenentations would drop their connection after the last packet, and simply re-intstanciate when a new request hits the stack. Robustness may be nothing more than the extent to which a client/server can reinstanciate the connection and restablish the precise state at the momement the last connection was dropped.
>
>So, my initial thread proposed:
>

use (www.VFPEnterpriseServer/MyData/MyApp) in zero
>set order to cust_id
>seek lcCust_Id

>
>The responses were: Well, "USE" is not persistent - and I agree. My argument is that nothing really persists and that the allusion of persistence is a function of how the connection object (syntax?) was engineered (implemented). [...snip...]

At least my reply was not just about the USE command being a persistent connection. As you said, persistense can be an illusion (examples includes the Matrix, Voodoo WebControls, Session handling, and my bank account).

But my point is that in an unconnected, low-bandwidth network as the Internet is today, the whole SEEK/SCAN method is extremelly inefficient. Record by record handling implies a lot of index traffic over the network, thus requiring that you "virtual persistence" reconnect once per record scanned. Think of a SEEK/SCAN construction as one isolated transaction per record (in fact, that's preety much what it is).

Now, take another slighltly different approach: a SQL Select statement (in a relational engine setting, not in a pure VFP one). What goes over the wire is a single statement, and what comes in return is also a single-shot result set (no matter if it is a few bits or a few megabytes).

That is many, many times easier to handle in a disconnected, low-badwith network. In fact, this is why SQL database engines are architected that way.

But going back to your original request, as I said, VFP allows you to handle such a kind of connection quite easy (although I guess MS is not making millions on it).

Not to make self-promotion, but take a look at this old article of mine. It proposses a scaled-down, simple and cheap database server using just VFP and COM+:
http://www.levelextreme.com/Magazine/July2002/Page22.asp

Of course, I'm here if you still don't believe me. ;-)