>><>>OUCH! SQL Server is not good at record processing. Unless you're doing something very simple inside the loop, my guess is it will be faster to pull the data into VFP, process it there, then send it back.
>>>
>>>Ouch, I don't believe you just said that!
>>>Everybody knows that VFP will do this fast, but how does NET cope with it
>>>speed/simplicity wise ?
>>>I don't believe what you just said, is something that is commonly adviced at NET codecamps. It would be like swearing in the (NET reborn's) church :0)
>>>
>>>If NET roadsters hv to go back to VFP garage every now and then, to
>>>do dirty their hands with 'service' like this, we don't hv to care for future of VFP.
>>>VFP Sales will rise together with NET sales and eventually there
>>>will be another VFP version <vbg>
>>
>>
>>What he meant is that SQL Server is not good/optimized for record processing. It is geared towards sets. Generally speaking I would prefer to to work the data outside (like VFP in his example). This does not mean that SQL Server can't do it. You can use a SQL Server cursor and manipulate/process it in a Store Procedure but it may not be the best option.
>
>I was just kidding :)
>
>Aldough I don't understand why NET is still 'denied ' such features/classes.
>If they really want VFP people to join NET flow, (and for NETsters to be more productive) then they should provide at least some encapsulated object/functionality simillar to VFP data session, where everything (or most) that VFP does with the data, should be possible.
>Sort of like VFP DML script available directly on (buffered) SQL data.
>As if you wld open all database tables in optimistic buffering mode, be able to do what ever you want with them, and then at the end simply issue .SaveAll() or .RevertAll()
>Transactions and all the rest should be automaticly performed.
>
>That would be having something BETTER then we already can do with VFP.
>I don't know precisely what LINQ does but it sure doesn't do this
>there4 is not enough :)
>
>If something like this existed in NET then I wld invest my time
>learning gazillion of interface and other objects&classes, and how to interact with above described DataHandlingDreamComeTrue via NET.MSSQL.Datasession object.
>
>Hence, that If I create application at my own (or Clients) premises then
>I want total(itarian) ownership/control over data.
>IM(R)O;
>Database without flexible frontend app. is pile of garbage on the harddisk, and so is the development tool that cannot have complete control over data it is trying to handle.
>I could also say something as radical as this ;
>'If I want no RI, then I should be able to disable it!.
>Otherwise, I don't consider to fully own my own data! But all that of course in specific level/mode of operation.
>From 'aerial viewpoint' MSSQL server can appear as it is now; perfectly robust, stable, with tons of RI, securities etc in place. But Dev.platform developed behind&arround it, in the same (MS) house should by all means have large 'back door' after necessary security clearances are obtained.
>That is magic of VFP success.
>
>So record based access, why not ?
>Scan/replace/Endscan Why not ?
>Full VFP DML set why not ?
>
>If so, then NET/MSSQL why not?, otherwise why bother ?
>
>Don't have to bother explaining that this is not possible because
>of this, and that because of other thing. All this is just my little daydream :)
>But One I wld pay for(!) to have it come true. Other then that
>I am not buying something I already have :)
>
>Money making is most of the time about selling the same thing over and over again; so who knows; maybe NET 9.0 / MSSQL 2018 (Last published version of NET!) will have something like that as default, and then we will be all adviced at that time to switch to radically new SPACE.NET.Studio and start all over again... <vbg>
>
>Cheers :)

Sergio,

The really brief answer is that something analogous to VFP data sessions is antithetical to the goals of .NET.