>That might be nice, but it is my understanding that usually, database servers simply don't work this way, and you (the programmer) has to get accustomed to work with data in a different manner.
>
>In a database server, you access the data through a query (SELECT statement). Indices are simply used internally, to optimize the queries, and perhaps to enforce RI.
The process could be a query - that's okay - but I don't want to have to code the query, adapt the cursor or build update parameter statements. I just want the reults - how they

>
>There is not much VFP, or other programming languages, can do about the manner in which the database offers us data.
I don't care how the data is offered - thats for the engineers to work out - I just want the data in the buffer after I call with SEEKEX(). I am not trying to make SEEK work - I am proposing an architecturaly transparent "SEEKEX()" - I have no idea how it works - I only want the results. How that happens would not be my concern:.

Am I just lazy, Hilamr:-) (hint - Yes, Terry is Lazy)

>
>You can fetch the entire table, but if the table is big, you are better off in just getting a small subset of the data at a time.

I have done this with SPs and pass-through - and I liked it - but the application is having to deal with nested cursors and parameter protocols.
>
>>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 :-).