>>>>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.
>>
>>Mike, I'd appreciate reading a bit more carefull here. Once a dataset is downloaded from any source (whether SQL server or any other database), you cannot use the SQL standard to manipulate it. ADO.NET, in itseft does not support any SQL, it just passes strings to a connection (either OLEDB or ODBC) and let whatever is connected to that handle the passed string.
>>

>>Try to download 3 tables independedly from any source (maybe three different sources) and then try to use SQL on the dowloaded datasets. Granted you could do some with LINQ, but it is no SQL standard. What is the reason to reinvent different DML methodologies again and again while we've got a SQL standard. I just don't get it. It is plain stupid and wrong. Why should it make a difference whether the data comes from a server or already is loaded in ADO.NET ??
>
>You probably know that a DataSet does not need to have the same structure as the underlying database. If you want to do a join between multiple tables, you can define the result set as a "table" in the DataSet.
>
>Are you saying you would like to be able to use SQL syntax to update the DataSet? I suppose that would be nice, although personally I do not find the native ADO commands unwieldy. In any case it doesn't seem like enough reason to blast the entire technology.

Not only updating, but getting newdatasets from a SQL select command that takes any dataset as an argument in its FROM and JOIN clauses. I'm not saying the native commands should disappear as they, like the xBase commands in VFP, provide a finer record oriented control over accessing the table. But at least let me treat a dataset like any other table that can be manipulated with SQL. (SQL-SELECT, SQL DELETE, SQL UPDATE)

I don't think they have to blast the technology, they have to implement this on top of what is already there. And it should have been implemented a long time ago. In stead they build on top of propriatary techniques like RDO and ADO.