Just to add to that:

A lot of .NEt developers use a business layer that talks to a data access layer. Once the data has been pulled into business objects as datatables (via a variety of fillmethods, including but not limited to stored procs) the data is in local 'cursors' and can be further joined, processed, scanned, serialized or just about anything I've ever done with data in fox. It can also be strong-typed so you are basically saying alias.fieldname to talk to a field. I can't use the foxpro commands that are second nature to me, but I don't really see there isn't a command to do what I want. I scan through a business object's cursor just as I would in VFE where we have been creating data objects for 10 years.

Plus, having extension classes, partial classes, genuine delegates and event handling - it is a lot to learn and some if it is pretty complicated but it is also very very powerful - and that includes in the area of handling SQL server data.

I do not have the live data dictionary I am used to with DBCX but I am working on creating similar metadata stores in .NET - though my mentors assure me I'm not going to need them as much as I did in VFP.



>>Hi Charles,
>>
>>>Regarding data munging - I'm finding that in Strataframe with strongly typed business object that filling multiple cursors and doing the kind of stuff we do in Foxpro is really not very difficult - different perhaps, but definitely not the nightmare I saw in .NET 1.1 out of the box. I had seriously underestimated the power of .NET to do this kind of stuff. I think some of it you would like very much. It really isn't all that different (of course that the framework was created by Fox guys with Fox expectations for data handling helped a lot <bg> )
>>
>>I'm not up to date how strate frame handles it. But to me that is not really the issue. It does not come out of the box, so it is only applicable to the developpers using strateframe.
>>
>>For data handling. I'm very picky. I've been spoiled with VFP having very good SQL support for local and remote data manipulation through the SQL standard. Unless full support for ANSI SQL and/or D (http://en.wikipedia.org/wiki/D_(data_language_specification)) for data manipulation it is a kludge in any way you describe it. One could stress again and again that it is not that limiting and it is not that difficult. But that is not the point. It is propriotary, non standard, non scalable solution. Why the hell was SQL not build into ADO.net from the beginning ?? Can anyone explain ??
>>
>
>I don't know about version 1 but ADO.NET now contains as much SQL Server support as you could want. Your apparent belief that .NET has only kludgey data features mystifies me. My suggestion is you learn a little more about ADO and then come back and complain about how bad it is. It's not bad at all, it's just different from VFP.