John,
Yes, it's been an interesting discussion, and I appreciate you and Rick stating your points. A few observations:
I do not disagree, especially since SQL Server is pretty smart about re-using precomplied queries and reentrance. OTOH, I go back to my previous point: Sometimes DBAs or other admins refuse to grant you those services and you're forced into doing client side munging. Yes, this does happen - but I see less and less of the "wall" these days, especially in SQL Server environments. A while back, I ran into someone who was reluctant to grant SP access. I demonstrated how SPs could reduce the # of instances of pushing out software updates. Made him a believer. I had another case where I wrote SPs in a test environment, and they were reviewed before going into production. I'm sure the Oracle side is still more rigid.
The main thing that is not as flexible in my opinion is the fact that you can't re-execute additional SQL/set based commands against your result sets. Once the data is there, you have to pretty much work with an array/collection based structure. This actually has some advantages - it can be very fast on mid sized sets of data for example (but also on the slow side with large sets of data). But it lacks a complex filtering and sorting engine to post process data...Yes, you can't re-execute full-blown, set-based queries on ADO.NET result sets. (Unless you pass the dataset to a Fox DLL, run the query, and return it back as XML). As a general rule, I believe that belongs in the back end.
But regardless....I think the sentence "lacks a complex filtering and sorting engine to post process data" can be debated on some level. ADO.NET has rowfilter capabilities that can utilize parent/child relationships (defined as ADO.NET relations). ADO.NET does have the ability to sort columns. And in ADO.NET 2.0, you can implement the equivalent of a SELECT DISTINCT to filter out duplicates based on a list of columns. ADO.NET 2.0 is faster than ADO.NET 1.0, which helps with these operations.
So some data-munging queries can be done in .NET - it might be a few more lines of code, or it could be one or more methods.
I won't say it's as powerful as what VFP can do with local data. But I won't say it's lacking either. Yes, you do have to do things differently. IMO, ADO.NET has more capabilities than what is sometimes believed.
To date I haven't run into a brick wall, though I've been in situations where I had the freedom to implement things in stored procs. And while others will disagree, I have actually found the process more efficient. There's something to be said for (as an example) implementing a stored proc to return the result sets for financial statements, where I can generate a result set that models (in structure and content) what goes on the report. Once the parameters and result sets are fully defined, I can develop and test independently of any middle-ware or client pieces. To be honest, if I were asked to develop a Fox app with a SQL back-end today, I would probably start out with that same model.
LINQ is interesting but I think VFP people will find it lacking. It's not going to provide the kind of data connectivity that we're used to in VFP. The real value of LINQ will be with data structures in general - specifically I expect it will be with business objects. From the stuff I've seen LINQ's data access features look like its weakest link. All the rest of the language features are hot, but as you say Data is the key and that's the part that's looking least fleshed out.
>
>A lot can and will change surely, but I wouldn't hold my breath to get xBase like functionality into the languages - and SQL is only part of the story anyway if you're talking xBase features missing in .NET <g>... At the risk of saying "ditto"....but from what I've seen and read so far, yes. (I haven't followed it in a month, so things might have already changed!)
I agree, good discussion.
Kevin
