Think of a SEEK/SCAN construction as one isolated transaction per record (in fact, that's preety much what it is).

I was suggesting that the programmer could USEEX() or SEEKEX(). The way it behaved would not be at all like they behave (in legacy)on a LAN. But, the results would be the same. Why does CREATEOBJECTEX appear to persist - because MS engineered it that way. Why don't USE, and SEEK persist and easily negotiate the architecture: Because MS engineered them that way.

What if MS engineered SEEKEX and USEEX to appear to persist and automatically, efficiently negotiate the architecture? Would that be easier than diluting our focus on project dleivery and interface design? Is it enough to be VFP developer - why do we have to learn VS.NET and SQL and SOAP, etc - if all that really needs to be done is to have MS engineer it?

My argument is that NET and SQL are over-kill in most of the market/

You can almost imagine a SEEKEX() function in VFP:
procedure SEEKEX(lcKey,lcDBF)
* establish the connection
* build an ADO or XML reference from a remote data source
* return it to the client with filled tags
endproc
? MyRomoteDBF.cust_ID && The unconcerned VFP developer gets his data


>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).

I realize this - but why should I, as a VFP develper be concerned with this. Let MS engineer the functionality to handle it. Make it transparent to me - and let me get back to what I do - writing VFP code. I could sell that functionaity to my customers. It is difficult sell them a whole slew of stuff they don't need.

>http://www.levelextreme.com/Magazine/July2002/Page22.asp
Thanks for the link :-).